Coordinator DB support ​

A useful support report explains the expected result, the observed result and the smallest sequence that reproduces the difference. Start with the Support center to check the behavior relevant to your query or connection.

Describe the request ​

Include the SQL, selected database, connection interface and output format. State whether the request uses the native client, HTTP or the embedded API. A transaction that spans several native requests has a different lifetime from a transaction sent over HTTP.

Use a small synthetic dataset that preserves the failing data shape. Include CREATE TABLE, the required INSERT statements, the failing query and its actual output. Describe whether the problem occurs on every run and whether it depends on another connection.

Collect diagnostics ​

For an HTTP failure, record the status and the X-Coordinator-Query-Id and X-Coordinator-Exception-Code response headers. For a completed server request, use its identifier to inspect the public request history:

SELECT type, query_duration_ms, exception_code, exception
FROM system.query_log
WHERE query_id = 'replace-with-the-request-id'
ORDER BY event_time;

Include effective settings relevant to the failure. A memory, processing-time or response-size limit is part of the reproduction, even when the same query succeeds with smaller input.

Remove private information ​

Remove passwords, API keys, authorization headers and application data before sharing a report. Use synthetic values consistently in both the reproduction and expected output. Browser request captures can contain credentials and should be reviewed before they are attached.

See the HTTP interface, query history and request limits for the exact public diagnostics.