-
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
Log the correlation ID when blocking queries fire #10689
Conversation
Knowing that blocking queries are firing does not provide much information on its own. If we know the correlation IDs we can piece together which parts of the snapshot have been populated.
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
edit: Woops, accidental close |
🍒 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/415616. |
🍒 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/415632. |
🍒✅ Cherry pick of commit 19f6e1c onto |
Knowing that blocking queries are firing does not provide much information on its own. If we know the correlation IDs we can piece together which parts of the snapshot have been populated. Some of these responses might be empty from the blocking query timing out. But if they're returning quickly I think we can reasonably assume they contain data.
Knowing that blocking queries are firing does not provide much
information on its own. If we know the correlation IDs we can
piece together which parts of the snapshot have been populated.
Some of these responses might be empty from the blocking
query timing out. But if they're returning quickly I think we
can reasonably assume they contain data.