FIX: Ensure non-long-polling requests are always spaced out #324
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When long-polling, after a request returns some data, message-bus will immediately begin another long-polling request to maintain a consistent stream of messages.
When not long polling, we do not expect a continuous stream of messages, and the client aims to make one request every
backgroundCallbackInterval
(default 60s).Before this commit, some long-polling logic was leaking into the non-long-polling requests. Under certain situations (e.g. a channel receiving very frequent messages), this could cause clients to start issuing non-long-polling requests every
minPollInterval
(100ms). This commit fixes the logic so that 'immediate retry' is only performed when in long-polling mode.