feat: ability to send query context for limit enforcement

[trevorwhitney]

What this PR does / why we need it:

This is a solution for enforcing query limits on queries that get split by Grafana. it is entirely opt-in and best effort, in that the most restrictive limit is always honored, so the headers cannot be used to get around limits. With this change, the Grafana datasource can now send the original query and time range with each split, so the limits for the original query can be enforced even when only evaluating a small "slice" of that query.

This is the backend change necessary for grafana/grafana#114112. In this example the split is hardcoded to 5m (rather than the default 24h) to make it easier to test against local data. As you can see, the volume requests stop after the first split fails, due to being over the overall limit.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[periklis]

LGTM

[gtk-grafana]

I might be seeing some bugs with this locally.

Sending a request that doesn't throw an error with the limits header:

X-Loki-Query-Limits-Context: 
{"Expr":"sum(count_over_time({service_name=~\\".+\\"} [5m])) by (detected_level)","From":"2025-11-17T12:08:29.92-06:00","To":"2025-11-19T12:08:29.92-06:00"} 

In the meta we see:

"totalBytesProcessed": 5109326,

When I run an index/stats call for the same query & duration
REQ:

http://localhost:3100/loki/api/v1/index/stats?query={service_name=~".+"}&start=1763402909920000000&end=1763575709920000000

RESP:

{
    "streams": 74,
    "chunks": 77,
    "bytes": 33970176,
    "entries": 72828
}

With limits config that looks like:

max_query_bytes_read:"1073741B"
...
version: "twhitney-query-limit-header-1ae2408"

Request that should fail:
totalBytesProcessed: 5109326
estimatedBytesProcessed: 33970176
max_query_bytes_read: 1073741

Also I'm getting a 500 response, shouldn't this be a 400?

 "A": {
            "error": "the query would read too many bytes (query: 39 MiB, limit: 1.0 MiB); consider adding more specific stream selectors or reduce the time range of the query",
            "errorSource": "downstream",
            "status": 500
        }

Although the actual response has a statusCode of 400, just the message has a "status" of 500
This is a bug in the datasource backend, not a Loki thing, nvm

[trevorwhitney]

I'm having trouble re-creating this, so I think we merge this, ship it to dev, and see if we can find a scenario this happens that we can share. The mismatch in our local data and how we're running Loki makes this difficult to repro.