Question
Flux query timeout error reason differs between server logs and HTTP response on InfluxDB 2.x
Ash Orbit
0 reputation · 26 May 2020, 22:50 UTC
89.2K views
Loading…
0 reputation · 26 May 2020, 22:50 UTC
I'm working with InfluxDB 2.x and trying to handle timeouts and cancellation consistently across the HTTP query API and write path. My goal is to reliably distinguish a server-side max-query-time termination from a client-side cancellation or a write timeout, but the error surfaces don't seem to line up.
From what I can tell, a Flux query that exceeds the configured max-query-time is cancelled and returns a query-level error reason, while writes that surpass the write timeout return a different error whose exact message varies between the native /api/v2/write endpoint and client libraries. The HTTP status code and payload for a timed-out request also appear to depend on version and deployment settings, so I'm not sure which signal is authoritative.
My uncertainty is where to anchor the handling logic: the HTTP status code, the Flux error reason, or the server log entry, given that client libraries may mask or reinterpret the underlying timeout.
Specifically:
/api/v2/query response reliably identifies a max-query-time termination versus a client-cancelled request?/api/v2/write guaranteed to carry a distinct status code from query timeouts in 2.x?30775 reputation · 27 May 2020, 07:02 UTC
The /api/v2/query endpoint returns a JSON object that contains an error key when the request fails. For a server‑side max‑query‑time termination this field always includes the phrase \"query timeout\" or \"max query time exceeded\". A client‑initiated cancellation, on the other hand, produces an error string that contains \"canceled\" or \"context canceled\". Checking the error string is the most consistent way to distinguish the two in 2.x releases.
Both write‑timeouts and query‑timeouts are reported with HTTP status 500 (Internal Server Error) or, in some configurations, 400 (Bad Request) if the request payload is malformed. There is no dedicated status code that separates write‑timeouts from query‑timeouts. The only reliable discriminator in the HTTP layer is the error message content.
Many official client libraries (e.g., influxdb‑go, influxdb‑python, influxdb‑js) map the server’s error field to language‑specific error types. If the library preserves the original error text, you can rely on the library’s error type to identify the cause. However, some wrappers replace the full message with a generic timeout error. For absolute certainty, inspect the raw HTTP response or correlate with the server logs.
influxdbmax-query-time (e.g., 1 s) in influxdb.conf and restart the server./api/v2/query and capture the JSON response.error field contains query timeout and that the server log shows a query timed out entry.error field contains canceled or context canceled while the log records a cancellation./api/v2/write to trigger a write timeout. Check that the response error includes write timeout and that the log entry matches.If you are unsure whether a particular client library preserves the original error message, let me know which library and version you are using; that will determine whether you can rely on the library’s error type alone.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.