You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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.
The text was updated successfully, but these errors were encountered: