Context Deadline Exceeded Leaves Flux Query Running in InfluxDB OSS 2.x

Answer first

In InfluxDB OSS 2.x there is no documented, universally supported public API to cancel a running Flux query by ID after a client timeout. The /api/v2/query?type=active endpoint is observability only. It can identify in-flight queries with an identifier, query text and elapsed time, but it does not provide a cancel operation in OSS. The supported way to bound the impact of orphaned queries in OSS is resource limits, not cancellation.

Enterprise and Cloud builds have had additional control endpoints in some releases; route registration differs by edition and build. Do not assume a cancel route exists in OSS because it is mentioned for other editions.

Confirmed facts vs likely explanation

Confirmed

• OSS 2.x query API returns context deadline exceeded or a 504 when the client or an intermediary times out.
• The active-query listing is a snapshot for diagnostics. It does not terminate queries.
• Write paths can discard partial batches on connection reset more promptly than query execution can be torn down.

Likely explanation

The HTTP handler derives the query context from the request. Cancellation only reaches the Flux engine at points where the engine checks that context. Long storage scans, grouping, sorting or a slow first result can run past the client deadline before a check occurs. A 504 usually means a reverse proxy, load balancer or gateway timed out. Whether the upstream connection is closed depends on that proxy's configuration, so InfluxDB may never observe a disconnect at all.

Steps that actually bound the problem in OSS

1. Pin the exact build. Run influxd version and note the OSS 2.x patch. Context propagation and active-query behavior changed across 2.x releases.
2. Read the effective configuration. Run influxd print-config and confirm the [query] section values actually in force for your instance: concurrency, queue-size, per-query memory and total memory. These are the OSS levers.
3. Separate proxy from server behavior. Reproduce with a direct connection and with the proxy in place. If the proxy keeps the upstream alive after a client timeout, the server will not see the abort.
4. Use active queries for detection only. Poll /api/v2/query?type=active after an abort to confirm orphaned work and correlate with logs. It is a diagnostic snapshot, not a control plane.

To reduce waste, keep query concurrency and memory caps conservative, ensure the proxy closes the upstream on client disconnect, and prefer query patterns that return early results.

One diagnostic detail that changes the recommendation

What exact influxd version and proxy/gateway sits in front of the query API? Version determines whether any cancel-related route exists in your build, and proxy timeout/keep-alive settings determine whether the server ever sees the client abort.