-
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
api: ensure v1/health/ingress/:service endpoint works properly when streaming is enabled #9967
Conversation
…treaming is enabled
…y when streaming is enabled Backport of #9967 to 1.9.x
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.
Thank you for making this change! I think this roughly works, but moving it into the rpcclient/health.Client
will ensure it is fixed in the right place for all callers.
I think when we chatted about it I suggested making the change in this spot, but now I realize that because we're having to switch the underlying cache, that isn't the case.
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.
LGTM with the one suggestion
🍒 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/345498. |
The streaming cache type for service health has no way to handle
v1/health/ingress/:service
queries as there is no equivalent topic that would return the appropriate data.This PR ensures that attempts to use this endpoint will use the old cache-type for now so that they return appropriate data when streaming is enabled.
Manual backport to 1.9.x #9968