Skip to main content

Settlement

What ack, drop, retry and retry_after become on a stream file and a pipe, which keep no consumer positions and acknowledge nothing.

A handler's outcome on a stream file or a pipe: only a copy the runtime publishes brings a message backThe handler's outcomeack, drop:reportedunsupported,loggedretry():the requeue isunsupported,loggedretry_after(d):the runtimepublishesa copyNothing records how far a service read:a restart resumes from a position it stored
The diagram as text
  1. The handler's outcome → ack, drop: reported unsupported, logged
  2. The handler's outcome → retry(): the requeue is unsupported, logged
  3. The handler's outcome → retry_after(d): the runtime publishes a copy
  4. Nothing records how far a service read: a restart resumes from a position it stored

Neither client records what a reader has handled. A delivery's ack and nack therefore report AckError::Unsupported at once, and the runtime logs it. An acknowledged message is not marked anywhere, and a requeued one does not come back. A service that restarts resumes from a position it stored itself.

A retry is the one outcome that brings a message back, and the runtime does all of it.

Retries​

A retry on a stream file or a pipe: the attempt cap decides between a copy, the dead-letter key and nothingretry_after(d), or retry() under a declared capthe retry-count header says which attemptmax_attempts: is this attempt below the cap?Below the cap:a copy, afterany delayAt the cap:a copy to thedead-letterkeyAt the cap,no dead letter:nothing iswrittenFile: the samestream key, readby the subscriptionPipe: the keyout_retry names,for the next stageThe delayed copy is held in the process:a crash before the timer fires loses it
The diagram as text
  1. retry_after(d), or retry() under a declared cap the retry-count header says which attempt → max_attempts: is this attempt below the cap?: a retry
  2. max_attempts: is this attempt below the cap? → Below the cap: a copy, after any delay: below
  3. max_attempts: is this attempt below the cap? → At the cap: a copy to the dead-letter key: at the cap
  4. max_attempts: is this attempt below the cap? → At the cap, no dead letter: nothing is written
  5. Below the cap: a copy, after any delay → File: the same stream key, read by the subscription: file
  6. Below the cap: a copy, after any delay → Pipe: the key out_retry names, for the next stage: pipe
  7. The delayed copy is held in the process: a crash before the timer fires loses it

A retry_after outcome, and a retry() on a registration that declares max_attempts or a dead-letter key, take this path. Neither transport counts its deliveries, so the attempt travels in the copy's retry-count header, and the first delivery counts as one. The cap is checked first. At the cap, a declared dead letter gets a copy, and without one the delivery is rejected and nothing is written.

Below the cap, the runtime drops the delivery and publishes a copy, after the delay of a retry_after. On a stream file, a stream key is both ends: the subscription reports the key it reads, and the copy is appended under it, so the mount site names nothing. A replay reads the copy only while it is still short of the end of the file.

On a pipe, the copy leaves on standard output for the next stage, so the mount site names its key with out_retry. A registration on a pipe that names none refuses to start.