Skip to main content
Reference
Helix query failures expose a stable machine-readable code separately from the human-readable diagnostic. Branch on the code; log or display the message. Messages can gain context over time and are not a compatibility contract.

HTTP error envelope

Every non-success response from POST /v2/query uses error for the static code and msg for the readable message:
The response never adds a separate code field. HTTP status classifications are unchanged, so use both the status and static code when deciding whether to retry. A non-JSON response from an older proxy or intermediary is still exposed by each SDK as readable details with no code.

Access the code in an SDK

Known Rust codes can also be parsed as QueryErrorCode. SDK wire fields remain open strings so a newer server’s unknown future code is preserved rather than being collapsed or rejected.

Other query boundaries

For gRPC, the status message remains human-readable and the same static code is attached as ASCII metadata under helix-error-code. gRPC status classes are unchanged. Embedded Rust errors expose error_code(). UniFFI errors carry two explicit fields named error and msg; generated Python, Node, and Go bindings pass that pair into their SDK error objects. Embedded callers never need to infer a code from exception text.

Stability and retry rules

  • Existing code strings are frozen compatibility identifiers. New codes may be added, so applications must preserve and safely handle unknown values.
  • A code describes the failure, not whether replaying a particular mutation is safe. Retry only idempotent work or work protected by an application-level idempotency key.
  • transaction_conflict is the only HTTP conflict classification and is normally retryable with bounded backoff.
  • Availability and lifecycle failures should be retried only after the named condition changes. Validation and planning failures require a corrected request or schema/index configuration.
  • internal_*, storage_error, and response_serialization_error are opaque by design. Retain the msg and server logs when escalating them.

Error-code reference

“Correctable” means whether a caller can change its request or deployment state to address the failure. Statuses list the current HTTP behavior; 400/503 and 400/500 indicate that the same code can arise at more than one boundary.

Request validation

Planning

Execution

Index lifecycle

Retryable conflicts

Availability and migration

Internal failures

Migrate direct HTTP consumers

The field names changed while their roles stayed the same: Old response:
New response:
Current SDKs read both shapes during migration. Direct HTTP consumers must move their code branch from code to error and their diagnostic read from error to msg.