-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
streaming: fix a couple bugs #9745
Conversation
Streaming can not be used for these queries because the near query paramter indicates a specific sort of the results, and that sort requires data that is not available to the client from the streaming API.
The materializer is often reset when an error is received. By resetting the retryWaiter we effectively never wait. The retryWaiter should only be reset when we get an event without error. This is done in Materializer.updateView().
🤔 Double check that this PR does not require a changelog entry in the |
10 minutes is the default blocking query timeout. Using the same value results in us hitting the expired cache entry bug frequently. By extending this TTL we at least mitigate the problem. The underlying bug still needs to be fixed.
🍒 If backport labels were added before merging, cherry-picking will start automatically. To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/326013. |
🍒✅ Cherry pick of commit 9aa8081 onto |
streaming: fix a couple bugs
useStreaming := s.agent.config.UseStreamingBackend && args.MinQueryIndex > 0 | ||
// useStreaming when a blocking query is requested, but not when the near | ||
// query parameter is set, because that requires data only available to the server | ||
// to sort the results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something we can actually fix later for streaming?
If a fix is possible but just not simple enough to do right away this seems like a good move to unblock folks. But if it's more that this feature is never going to be practice for streaming for some reason, I wonder if we should actually not fallback now and just make it a hard limitation of the feature that we document. I'd rather folks trying it out find out these limitations before it's GA etc. if we aren't actually going to have a fix for them.
I've not thought though if it's feasible to ever support this for streaming?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote this yesterday before it was merged but forgot to actually submit it :( Sorry. Not to late though if we do decide to do something else for next release!
Details in the commit messages