feat: Weighted Query Laning Strategy

[mshahid6]

Description

Adds a new WeightedQueryLaningStrategy (strategy: "weighted") that scores queries by how many configured thresholds they breach and assigns them to graduated lanes with different capacity limits.

The existing HiLoQueryLaningStrategy uses a simple binary high/low split — any single threshold breach sends a query to the low lane. This misclassifies queries that are expensive on one dimension but cheap on others (e.g., many segments but cheap per-segment). The weighted strategy provides more nuanced lane assignment: a query breaching 1 threshold gets a different lane than one breaching 4.

Same threshold types as ThresholdBasedQueryPrioritizationStrategy:

• periodThreshold — how far in the past the data is
• durationThreshold — how large the query interval is
• segmentCountThreshold — number of segments involved
• segmentRangeThreshold — total segment time range

Each breach adds 1 to the query's score (this can be changed to make scoring different for each threshold). The query is assigned to the lane with the highest minScore it meets. Score 0 = no lane (runs in default pool). Existing caller-set lanes in query context are preserved.

Example config

{
"laning": {
"strategy": "weighted",
"periodThreshold": "P1M",
"durationThreshold": "P1D",
"segmentCountThreshold": 1000,
"segmentRangeThreshold": "P6M",
"lanes": {
"low": { "minScore": 1, "maxPercent": 30 },
"very-low": { "minScore": 3, "maxPercent": 10 }
}
}
}

A query breaching 2 thresholds (score=2) goes to low (30% capacity cap). A query breaching all 4 (score=4) goes to very-low (10% cap). When a lane is full, excess queries get HTTP 429.

Release note

New query laning strategy weighted that scores queries by how many thresholds they breach (segment count, interval duration, data age, segment range) and assigns them to configurable graduated lanes with different capacity limits, providing more nuanced lane assignment than the existing binary hilo strategy.

---

Key changed/added classes in this PR

• WeightedQueryLaningStrategy
• QueryLaningStrategy
• WeightedQueryLaningStrategyTest
• QuerySchedulerTest

[can add to docs once reviewed]

This PR has:

• been self-reviewed.
• using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[FrankChen021]

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

[jtuglu1]

LGTM overall, few minor comments

[FrankChen021]

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

[FrankChen021]

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

[jtuglu1]

Largely LGTM. Could we add docs for this strategy as well?

[jtuglu1]

Thanks, looks good – one last thing then ✅