Get desktop application:
View/edit binary Protocol Buffers messages
Details for ACCESS_DENIED errors.
The friendly name of the operation that was denied.
The username of the user who was denied access.
The permission that was required for this operation.
ErrorMetadata provides actionable information for error enum values to enable automated code generation, documentation, and consistent error handling across the Kurrent platform. It was modeled to support a single details type per error code to simplify code generation and validation. If multiple detail types are needed for a single error code, consider defining separate error codes for each detail type. Or, use a union type (oneof) in the detail message to encapsulate multiple detail variants within a single detail message. More however DebugInfo and RetryInfo can and should be added to any error regardless of this setting, when applicable. This annotation is applied to enum values using the google.protobuf.EnumValueOptions extension mechanism. It enables: - Automatic gRPC status code mapping - Code generation for error handling utilities - Documentation generation - Type-safe error detail validation Usage Example: enum StreamErrorCode { REVISION_CONFLICT = 5 [(kurrent.rpc.error) = { status_code: FAILED_PRECONDITION, has_details: true }]; } See individual field documentation for conventions and defaults.
Maps the error to a standard gRPC status code for transport-level compatibility. This field is REQUIRED for every error annotation. Use standard gRPC status codes from `google.rpc.code`. Code generators use this to: - Map errors to gRPC status codes automatically - Generate HTTP status code mappings - Create transport-agnostic error handling
Indicates whether this error supports rich, typed detail messages. Defaults to false (simple message string only). The message type name must be derived from the enum name by convention. Mask: {EnumValue}ErrorDetails, {EnumValue}Error, {EnumValue} Examples: ACCESS_DENIED -> "AccessDeniedErrorDetails", "AccessDeniedError" or "AccessDenied" SERVER_NOT_READY -> "ServerNotReadyErrorDetails", "ServerNotReadyError" or "ServerNotReady" Code generators use the message type name to: - Validate that the detail message matches the expected type - Generate type-safe error handling code - Create accurate documentation
Details for NOT_LEADER_NODE errors.
Information about the current cluster leader node.
Information about a cluster node.
Used in:
The hostname or IP address of the node.
The gRPC port of the node.
The unique instance ID of the node.
The canonical server error codes for the Kurrent Platform gRPC APIs. These errors represent common failure modes across all Kurrent services.
Default value. This value is not used. An error code MUST always be set to a non-zero value. If an error code is not explicitly set, it MUST be treated as an internal server error (INTERNAL).
Authentication or authorization failure. The client lacks valid credentials or sufficient permissions to perform the requested operation. Common causes: - Missing or invalid authentication tokens - Insufficient permissions for the operation - Expired credentials Client action: Check credentials, verify permissions, and re-authenticate if necessary. Not retriable without fixing the underlying authorization issue.
The request is malformed or contains invalid data. The server cannot process the request due to client error. Common causes: - Invalid field values (e.g., empty required fields, out-of-range numbers) - Malformed data formats - Validation failures Client action: Fix the request data and retry. Not retriable without modifying the request.
The server is not the cluster leader and cannot process write operations. In a clustered deployment, only the leader node can accept write operations. Common causes: - Client connected to a follower node - Leader election in progress - Network partition Client action: Redirect the request to the leader node indicated in the error details. Retriable after redirecting to the correct leader node.
The operation did not complete within the configured timeout period. Common causes: - Slow disk I/O during writes - Cluster consensus delays - Network latency - Heavy server load Client action: Retry with exponential backoff. Consider increasing timeout values. Retriable - the operation may succeed on retry.
The server is starting up or shutting down and cannot process requests. Common causes: - Server is initializing (loading indexes, recovering state) - Server is performing graceful shutdown - Server is performing maintenance operations Client action: Retry with exponential backoff. Wait for server to become ready. Retriable - the server will become available after initialization completes.
The server is temporarily overloaded and cannot accept more requests. This is a backpressure mechanism to prevent server overload. Common causes: - Too many concurrent requests - Resource exhaustion (CPU, memory, disk I/O) - Rate limiting triggered Client action: Retry with exponential backoff. Reduce request rate. Retriable - the server may accept requests after load decreases.
An internal server error occurred. This indicates a bug or unexpected condition in the server. Common causes: - Unhandled exceptions - Assertion failures - Corrupted internal state - Programming errors Client action: Report to server administrators with request details. May be retriable, but likely indicates a server-side issue requiring investigation.