Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

debugging multiple incorrect invocations of a callback could be much easier #41

Open
davepacheco opened this issue Feb 12, 2019 · 0 comments

Comments

@davepacheco
Copy link
Contributor

It's a programmer error (i.e., a violation of the intended API) for a vasync pipeline stage to invoke its completion callback more than once. It would be nice if vasync detected this immediately when it happened.

Today, the callbacks passed to all stages are the same function, and it always just advances the pipeline to the next stage (or completes it, in the case of the last stage). vasync does detect when you've invoked it too many times. So in the case I'm describing, you usually do get a thrown exception, but it's way later than the problem happened (the dreaded pipeline callback invoked after the pipeline has already completed).

For example, suppose there are 5 pipeline stages, and the first one invokes its callback more than once. Assuming the other stages eventually do invoke their callbacks, vasync detects a problem when it gets a 6th callback for a pipeline having only 5 stages. But it's way later than the problem originally happened. It would be much better to detect this as soon as any stage invokes its callback twice.

This could definitely change the behavior of programs that are working (admittedly somewhat by accident). We likely would want to bump the major version for this change. But it'd be worthwhile, as this is one of the most common issues with vasync.pipeline, and it's a pain to debug today.

This likely affects other functions, too (besides vasync.pipeline).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant