Error Handling

The DeRec protocol defines explicit mechanisms for signaling and handling errors during protocol execution. Errors may occur due to invalid messages, failed validations, incompatible protocol states, or operational conditions such as unavailable Helpers.

This section defines how errors are represented at the protocol level and how implementations should interpret and propagate them.

Error Categories

Errors in DeRec fall into three broad categories:

Category	Description
Protocol Errors	Violations of protocol rules such as invalid message structure, incorrect identifiers, or invalid state transitions.
Operational Errors	Temporary conditions such as Helper unavailability, network failures, or timeouts.
Validation Errors	Failures during cryptographic or semantic validation of protocol data (for example invalid shares or mismatched identifiers).

These categories help implementations determine whether an operation may be retried or must be treated as a permanent failure.

Message-Level Error Signaling

Many DeRec protocol messages include a result field that indicates whether the request was processed successfully.

Example structure:

result {
    status: StatusEnum
    memo: string
}

StatusEnum

Status	Meaning
Ok	The request was processed successfully.
Error	The request failed due to protocol or validation errors.

The optional memo field may provide additional context for debugging or logging purposes.

The memo field is informational and should not be relied upon for protocol logic.

Validation Failures

Implementations must validate incoming messages before processing them.

Examples of validation failures include:

• Missing required fields

• Invalid identifiers (secret_id, version, replica_id)

• Unexpected protocol state — e.g. a flow initiated on a channel whose role does not permit it (role-mismatch), or a replica-mode flow on a protocol instance that was not configured with a replica_id

• Cryptographic validation failures

• Share decoding or commitment verification failures

• Replica pairing carrying a missing or unexpected replica_id in its CommunicationInfo

When validation fails:

• The message must be rejected.

• An error status should be returned if the protocol flow defines a response.

Cryptographic Validation Errors

Certain flows require cryptographic validation.

Examples include:

• Verification flow hash mismatch

• Invalid share commitments

• Share reconstruction failures

In these cases:

• The invalid data must be discarded.

• The share must not be used in reconstruction.

• Recovery may still succeed if enough valid shares remain (≥ t).

Recovery Failure

Recovery may fail when the Owner identity (Owner or any Replica acting on its behalf) cannot obtain enough valid shares.

Typical causes include:

• Insufficient reachable Helpers

• Invalid or corrupted shares

• Helper data loss

• Helper refusal to participate

• Unresolved conflict between sibling Replicas — Helpers report the same (secret_id, version) with two different replica_ids and the application has not yet picked a winner. See Conflict resolution.

Recovery failure does not necessarily indicate protocol misuse. It may be the result of operational conditions or Helper availability.

Error Propagation in Implementations

While the protocol defines message-level error signaling, implementations typically use structured error types internally. For example, an implementation may represent errors using language-specific error types that map to protocol outcomes.

Typical implementation behavior:

1. Validate incoming messages.

2. Map validation failures to protocol error responses.

3. Propagate internal errors using implementation-specific error types.

The DeRec protocol does not mandate a specific programming language error model. Implementations may use language-specific mechanisms such as exceptions, result types, or error codes.

Retry Semantics

Some errors represent temporary conditions and may be retried.

Retryable conditions include:

• Helper temporarily unavailable

• Network disruption

• Timeout during recovery requests

Non-retryable conditions include:

• Invalid message format

• Share validation failure

• Protocol version incompatibility

Implementations should avoid infinite retries and should apply appropriate backoff strategies when retrying operations.

Deterministic Error Handling

To ensure interoperability across implementations:

• Message validation rules must be deterministic.

• Invalid messages must be rejected consistently.

• Protocol flows must define clear success and failure outcomes.

Consistent error handling ensures that independent implementations behave predictably under failure conditions.