Get desktop application:
View/edit binary Protocol Buffers messages
Details for APPEND_RECORD_SIZE_EXCEEDED errors.
The name of the stream where the append was attempted.
The identifier of the record that exceeded the size limit.
The actual size of the record in bytes.
The maximum allowed size of a single record in bytes.
Details for APPEND_TRANSACTION_SIZE_EXCEEDED errors.
The actual size of the transaction in bytes.
The maximum allowed size of an append transaction in bytes.
Details for STREAM_ALREADY_EXISTS errors.
The name of the stream that already exists.
Details for STREAM_ALREADY_IN_APPEND_SESSION errors.
The name of the stream that appears multiple times.
Details for STREAM_DELETED errors.
The name of the stream that was deleted.
Details for STREAM_NOT_FOUND errors.
The name of the stream that was not found.
Details for STREAM_REVISION_CONFLICT errors.
The name of the stream that had a revision conflict.
The expected revision that was provided in the append request.
The actual current revision of the stream.
Details for STREAM_TOMBSTONED errors.
The name of the stream that was tombstoned.
Error codes specific to the Streams API. These errors represent failure modes when working with streams of records.
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).
The requested stream does not exist in the database. Common causes: - Stream name typo or incorrect stream identifier - Stream was never created (no events appended yet) - Stream was deleted and not yet recreated Client action: Verify the stream name is correct. Create the stream by appending to it. Recoverable by creating the stream first (append with NO_STREAM expected revision).
The stream already exists when an operation expected it not to exist. Common causes: - Attempting to create a stream that already has events - Using NO_STREAM expected revision on an existing stream - Race condition with concurrent stream creation Client action: Use the existing stream or use a different expected revision. Recoverable by adjusting the expected revision or using the existing stream.
The stream has been soft deleted. Soft-deleted streams are hidden from stream lists but can be restored by appending to them. Common causes: - Stream was explicitly soft-deleted via delete operation - Attempting to read from a soft-deleted stream Client action: Restore the stream by appending new events, or accept that the stream is deleted. Recoverable by appending to the stream to restore it.
The stream has been tombstoned (permanently deleted). Tombstoned streams cannot be restored and will never accept new events. Common causes: - Stream was explicitly tombstoned via tombstone operation - Administrative deletion of sensitive data - Attempting to write to or read from a tombstoned stream Client action: Stream is permanently removed. Create a new stream with a different name if needed. Not recoverable - the stream cannot be restored.
The expected revision does not match the actual stream revision. This is an optimistic concurrency control failure. Common causes: - Another client modified the stream concurrently - Client has stale state about the stream revision - Race condition in distributed system Client action: Fetch the current stream revision and retry with the correct expected revision. Recoverable by reading the current state and retrying with proper optimistic concurrency control.
A single record being appended exceeds the maximum allowed size. Common causes: - Record payload is too large (exceeds server's max record size configuration) - Excessive metadata in properties - Large binary data without chunking Client action: Reduce record size, split large payloads across multiple records, or increase server limits. Recoverable by reducing record size or adjusting server configuration.
The total size of all records in a single append session exceeds the maximum allowed transaction size. Common causes: - Too many records in a single append session - Combined payload size exceeds server's max transaction size - Attempting to write very large batches Client action: Split the append into multiple smaller transactions. Recoverable by reducing the number of records per append session.
The same stream appears multiple times in a single append session. This is currently not supported to prevent complexity with expected revisions and ordering. Common causes: - Accidentally appending to the same stream twice in one session - Application logic error in batch operations Client action: Remove duplicate streams from the append session or split into multiple sessions. Recoverable by restructuring the append session to reference each stream only once.
An append session was started but no append requests were sent before completing the stream. Common causes: - Client completed the stream without sending any AppendRequest messages - Application logic error Client action: Ensure at least one AppendRequest is sent before completing the stream. Recoverable by properly implementing the append session protocol.