DeadLetterStore

DeadLetterStore = "off" | "metrics" | "memory" | "persistent"

Defined in: src/deadletters/DeadLetterQueueOptions.ts:38

Where captured dead letters are kept.

One axis, four rungs, ordered by how much of the letter is retained: nothing at all, the bare fact aggregated into a counter, the whole letter in a bounded ring, that ring plus a durable log. Each rung costs strictly more than the one below and answers strictly more questions.

A storage vocabulary on purpose, and deliberately not a second copy of the failure vocabulary ProjectionOptions introduced (retry-and-fail / retry-and-skip / fail / skip). That one answers “what should happen when handling fails”; this one answers “where does the letter go once it already has”. The two compose — a projection that skips publishes a dead letter, and this decides whether the queue keeps it — so folding them into one enum would have made two independent decisions look like one.

metrics exists because retaining a payload is a different decision from observing a rate. Under memory the queue holds a strong reference to every undeliverable message, which is a data-protection question the moment a payload carries anything about a person — and a counter is not. There is no way to approximate the posture with the other rungs: maxEntries is validated positiveInt, so the smallest ring still keeps one live payload for a whole retention window. An operator who wants the alert without the evidence locker has to be able to say so.

There is no log arm. Dead letters are not logged today and never were: DeadLetterRef holds no logger, it publishes on the event stream and returns. Naming the default after a log line the framework does not emit would document a behaviour into existence (#1000 tracks the docs that already claim it).