fix: fix query context precedence layer for datasource-level per-segment timeout#19654
fix: fix query context precedence layer for datasource-level per-segment timeout#19654jtuglu1 wants to merge 2 commits into
Conversation
1b93d75 to
de098fe
Compare
de098fe to
af877ed
Compare
FrankChen021
left a comment
There was a problem hiding this comment.
I have reviewed the code for correctness, edge cases, concurrency, and integration risks; no issues found.
Reviewed 4 of 4 changed files.
This is an automated review by Codex GPT-5.5
| transition(State.NEW, State.INITIALIZED); | ||
|
|
||
| userContextKeys = new HashSet<>(baseQuery.getContext().keySet()); | ||
| final Set<String> effectiveUserKeys = |
There was a problem hiding this comment.
nit: since it's not really clear from the variable names (userContextKeys vs userProvidedContextKeys), can you add a comment here on the difference between userContextKeys and userProvidedContextKeys
There was a problem hiding this comment.
Agreed. I've refactored since I didn't really want to leak this context override logic (per segment timeout, etc.) into the query handler code.
0e0d020 to
bf04b61
Compare
FrankChen021
left a comment
There was a problem hiding this comment.
I have reviewed the code for correctness, edge cases, concurrency, and integration risks; no issues found.
Reviewed 12 of 12 changed files.
This is an automated review by Codex GPT-5.5
Description
Currently, per-datasource, per-segment timeout can be not set if there's a hardcoded static default query context (
druid.query.default.context.perSegmentTimeout). This ensures the evaluation precedence for the per-segment timeout is as follows (from highest to lowest):druid.query.default.context.perSegmentTimeout)Also adds the perSegmentTimeout context key so it's easy to auto-complete in the UI.
Release note
Fix query context precedence layer for datasource-level per-segment timeout.
This PR has: