Crate zerodds_durability_service 

Standalone DDS Durability-Service daemon (ADR 0009).

Crate zerodds-durability-service. Safety classification: STANDARD.

From an RTPS point of view the service is just another participant. For each served topic it:

1. Ingests via a RELIABLE / TRANSIENT_LOCAL / KEEP_ALL reader — it receives every sample the application writers publish (and, thanks to TRANSIENT_LOCAL, the writer history if it joins late).
2. Stores each sample in a DurabilityStore (sqlite/file/in-memory).
3. Replays via a TRANSIENT_LOCAL / KEEP_ALL writer — a late-joining reader matches it and the standard RTPS path delivers the history. This keeps working after the original writer’s process has died.
4. Startup-sync: on serve the replay writer is primed from the store, so PERSISTENT history survives a full service restart with no application writer present.

Scope (increment 1)

Unkeyed topics (RawBytes = single instance). The replay writer assigns its own sequence numbers — a durability service is a new logical source, so the original writer’s sequence numbers need not be preserved. Per-instance history for KEYED topics + exact sequence preservation need the per-sample KeyHash/sequence exposed on the reader API and are a documented follow-up.

Structs

DurabilityService

The durability daemon. Uses TWO participants per domain — one for ingest (reader) and one for replay (writer) — that mutually ignore each other. This is set up before any endpoint exists, so the ingest reader can never match the replay writer (race-free echo-loop prevention). Both serve any number of TRANSIENT/PERSISTENT topics over a single DurabilityStore.

Enums

ServiceError

Errors from the durability daemon.

Type Aliases

Result

Result alias.