Skip to main content

Lifecycle walkthrough

This walkthrough follows one MANAGED Schedule. It focuses on the durable boundaries an application or operator needs to understand.

1. Prepare the operation​

Preparation fixes the Route, physical source partition, commandId, delayMessageId, canonical command bytes, and retry identity before network I/O. Retrying the same logical operation reuses that prepared object; it does not generate a new identity after a timeout.

2. Queue the Command​

The guarded ingress transport writes the prepared bytes to a Kafka or Pulsar Command Topic partition. A queued receipt proves Broker durability at a Source Position. It does not prove that validation passed or that a Delayed Message now exists.

3. Apply in Shard order​

The Delay Shard consumes every Client Command and System Mutation in Source Position order. It atomically writes the authoritative result, current message state, indexes, deduplication state, and applied source position to its RocksDB database. Only after the synchronous write succeeds may the source record be acknowledged.

A successful Schedule application creates the managed Delayed Message. A deterministic rejection records a stable result without creating one.

4. Wait, Claim, and admit​

The persistent Timeline makes a message discoverable when it becomes eligible. A Claim reserves scheduler work but remains reversible. The scheduler must then append a Publish Admission to the Shard Log. Only after that mutation is applied and the message is durably PUBLISHING may a producer call leave the process.

This is the cancellation boundary: Cancel may win before Publish Admission; after admission, the system must resolve the existing attempt instead of pretending it never started.

5. Record the destination outcome​

The Kafka or Pulsar adapter classifies the available side-effect evidence as published, definitely not published, or uncertain. A producer callback never updates RocksDB directly. It becomes a Publish Outcome mutation in the same Shard Log so it is ordered with Cancel, Reschedule, retry, expiration, and operator control.

UNCERTAIN is intentionally durable. It means the destination may have accepted the operation even though Nereus Delay cannot prove that result; an automatic retry could therefore create a duplicate.

6. Query or recover​

Queries distinguish queued Command state, applied Command results, and Delayed Message state. After a failure, a new owner restores an allowed checkpoint, replays the Shard Log after that checkpoint, and crosses the activation barrier before accepting new work. Existing PUBLISHING or UNCERTAIN attempts remain visible to evidence recovery.

Next, read Schedule flow for the command path and Due, Claim, and Publish Admission for the point-of-no-return boundary.