Repository navigation
2.4 Error Handling
Unified backend failures live in BackendError. Structured ZeroMQ transport failures use ZmqMessageError (feature zmq) and map into BackendError on the hybrid adapter. Tip for this page: 08d2f28 / #55.
| Variant | Meaning |
|---|---|
InitializationError(String) |
Setup / model load / connect failures |
ProcessingError(String) |
Failures during process_batch
|
ModelError(String) |
Save/load / filesystem I/O |
CommunicationError(String) |
Transport, framing, structural decode, closed sockets, second held sibling |
InvalidInput(String) |
Caller/payload validation (incl. hybrid envelope payload Validate failures) |
Protocol(ProtocolError) |
Wire-valid IpcMessage that is the wrong variant for this call (new in #55) |
Display strings (for example Initialization failed: …, Invalid input: …) come from thiserror 2.x derives since 5e4562b (LIM-1451, was 1.0). Display text, Error::source (None for the string variants; Protocol is transparent, so its Display equals the inner ProtocolError and its source is None), and variant matches are unchanged, and unit tests in src/error.rs now pin them.
Exhaustive matches on BackendError need a Protocol arm. Wire version stays 1. The REST mapper still treats Protocol as a backend failure (HTTP 502); the router does not expose hybrid-flow sockets (CHANGELOG Unreleased).
| Variant | Meaning |
|---|---|
UnexpectedVariant { found, expected } |
Decoded/validated message was not the variant this receive method accepts; frame already consumed |
Matchable outcomes from ZmqMessagePublisher / ZmqMessageSubscriber: InvalidConfig, Setup, Validation, Encode, FrameTooLarge, Envelope, UnexpectedFraming(FramingFault), WouldBlock, HighWaterMark, Closed, Transport. See 3.4.
flowchart TD
Rust["RustBackend"] --> BE["BackendError"]
ZmqRO["ZmqIpcBackend"] --> BE
Hybrid["ZmqHybridFlowBackend"] --> ZME["ZmqMessageError"]
ZME -->|"map_transport_error"| BE
Hybrid -->|"wrong variant"| Proto["BackendError::Protocol"]
Hybrid -->|"Validate fail"| Inv["BackendError::InvalidInput"]
BE --> Caller["IpcBackend / HybridFlowBackend caller"]
| Outcome | Result |
|---|---|
| Nothing queued | Ok(None) |
| Expected variant | Ok(Some(...)) |
| Sibling held / second sibling / framing / closed |
CommunicationError (or mapped from ZmqMessageError) |
| Unrelated variant | Protocol(UnexpectedVariant) |
Payload fails Validate
|
InvalidInput |
Sources: src/error.rs, src/zmq_message/hybrid.rs, src/trait_def.rs
- Home
- 1. Overview
- 1.1. Getting Started
- 1.2. Architecture Overview
- 1.3. Crate Exports and Module Map
- 2. Core Abstractions
- 2.1. IpcBackend Trait
- 2.2. HybridFlowBackend Trait
- 2.3. BackendFactory and BackendType
- 2.4. Error Handling
- 3. Backend Implementations
- 3.1. RustBackend
- 3.2. ZmqIpcBackend
- 3.3. ZMQ Readout Parsing and Golden Frames
- 3.4. Structured ZeroMQ IpcMessage Transport
- 4. IPC Protocol and Data Models
- 4.1. IpcMessage Protocol
- 4.2. Batch Data Types
- 4.3. NeuromodulatorSnapshot and Neuromodulator Packet
- 4.4. StimulusBatch and Runtime Ingress
- 4.5. Deserialization Hooks and Model Compat Aliases
- 5. Validation and Wire Compatibility
- 5.1. Validation Framework and ProtocolLimits
- 5.2. ValidationError and ValidationKind
- 5.3. WireCompatibility and Envelope Decoding
- 5.4. Canonical Wire-v1 Encoding
- 6. corpus_ipc_server HTTP Server
- 6.1. REST API Endpoints
- 6.2. Server Configuration and Deployment
- 7. Build, Dependencies, and Quality Gates
- 7.1. Cargo Features and Dependency Isolation
- 7.2. Testing Strategy
- 7.2.1. Wire-v1 Golden Test Vectors
- 7.2.2. Property-Based Wire Tests
- 7.3. CI, Coverage, and Release Qualification
- 8. Project History and Licensing
- 8.1. Naming History and Completed Renames
- 8.2. Licensing
- 9. Glossary