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

Notifications Can Be Lost #174

Open
daiyzee opened this issue Aug 31, 2019 · 2 comments
Open

Notifications Can Be Lost #174

daiyzee opened this issue Aug 31, 2019 · 2 comments

Comments

@daiyzee
Copy link

daiyzee commented Aug 31, 2019

There is a race condition with progress notifications. A notification can occur before
the progress callback is attached to a promise and unlike the reject or done callbacks which are stored and triggered they will be lost.
I have a fix for it using a list that is flushed when the progress is attached.

@saturnism
Copy link
Member

saturnism commented Aug 31, 2019

What should be the right behavior for a single callback vs if there are multiple callbacks? I.e., we can't guarantee that all notifications are buffered and replayed for every new callback registration, since we don't know how many notifications there will be, and can add to unnecessary memory consumption.

If we do this only for the first registration, then the subsequent registrations may have different behaviors.

If we do this for all progress callback registrations, if each progress handler does work for every notification, it may also be undesired. I would then want to collapse/dedupe the notifications to the last one, which is similar to the current behavior.

To detect 100%, I would listen to done/fail instead.

What is the use case in this particular use case where not a single notifications can be missed?

Thanks!

@daiyzee
Copy link
Author

daiyzee commented Sep 2, 2019

Hi,

You are correct in that as multiple progress callbacks can be attached asynchronously to the promise it cannot be guaranteed that all progress callbacks will receive all notifications.

That being said, I have not yet come across a scenario where using multiple progress recipients has been useful, however guaranteed notifications for a promise that uses the progress mechanism certainly has been.

The use case that highlighted notifications being lost was when attaching promises to a I/O stream/pipe to deliver data asynchronously to the consumer. Data is delivered on the progress() callback and done()/reject() is called when the data stream completes in success or error. Data cannot be lost in this scenario.

Maybe if multiple guaranteed progress notifications were required this could be achieved by using multiple promises and chaining rather than a single promise with multiple recipients.

Thanks.

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

No branches or pull requests

2 participants