Query-scheduler worker: don't treat cancel as an error #6767
Conversation
Could be the user closed the tab, or it's a sharded query and some other shard errored. Whatever the cause, cancellation is not an error. Two effects: the worker won't log "context canceled", and it will process the next request immediately. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
|
The CHANGELOG has just been cut to prepare for the next Mimir release. Please rebase |
| continue | ||
| backoff.Wait() | ||
| continue | ||
| } |
There was a problem hiding this comment.
I agree with the intent of this change. However, we'll now not log anything if the query is cancelled because the scheduler told the querier to cancel the query, which might make debugging issues harder.
Perhaps we should add an info-level log statement around line 177 below if the query is explicitly cancelled by the scheduler? Even better would be to cancel the context created on line 146 with an error like "query cancelled by scheduler" and then make sure this is logged somewhere or attached to the query trace.
There was a problem hiding this comment.
Would this happen if the user's client has a timeout shorter than Mimir takes?
This is the case I don't want to log for.
It should be visible as an event in the trace.
There was a problem hiding this comment.
The querier won't know what caused the cancellation - it could be that the user cancelled the query, or it could be that something in the chain between the user and the querier timed out and cancelled the query, for example.
There was a problem hiding this comment.
Still sounds like I don't want to see the log here.
The component taking a decision about canceling can log it.
There was a problem hiding this comment.
I think there's value in adding something to the querier's trace span to say "received cancellation from scheduler" - we've had a number of context cancellation-related issues in this part of the codebase lately, and being very explicit like this would have been helpful in debugging the issues.
What this PR does
This is the same as #4648 but for scheduler-processor.
When a query returns an error value, check whether that error is actually a cancellation before acting.
Two effects: the worker won't log "context canceled", and it will process the next request immediately.
Could be the user closed the tab, or it's a sharded query and some other shard errored. Whatever the cause, cancellation is not an error.
Checklist
CHANGELOG.mdupdated