Dead letters

Eventing 6 · 3:21

When delivery to a receiver keeps failing, the event becomes a dead letter that records its reader and the reason, and you can send it again. The video builds on the channel delivery of Eventing 4.

Download the mp4Recorded on 2026.2

What it covers

The delivery block in the channel document, with retries, retryDelays and their defaults
One durable reader per integration in weikio get readers
Retries after the receiver stops, until the event becomes a dead letter
The letter and its reason in weikio deadletters list and weikio deadletters show
Finding the letter on the Dead letters page under Events in the admin UI
Sending the letter again with weikio deadletters resend, or removing it with discard

Commands in this video

Terminal

$ weikio get readers sandbox/invoice-created --env devtest
$ weikio deadletters list --env devtest
$ weikio deadletters show --seq 1 --env devtest
$ weikio deadletters resend --seq 1 --env devtest -y

Transcript

0:02Earlier Eventing videos built a channel whose deliveries reach the receiver.
0:06This video follows an invoice the receiver turns away,
0:09from its failed deliveries to a resend.
0:15A new invoice lands in invoice-files each minute.
0:18The subscription passes it onward, first through its filter, then through its step.
0:24Each delivery lands at the receiver, for now.
0:27The channel has two readers: the integration that delivers, and invoice-watcher.
0:37The channel is now a document of its own.
0:39Its delivery block governs a failing delivery:
0:42how many deliveries an event gets, and the waits between them.
0:46Those values: three deliveries, ten seconds apart.
0:50Left at defaults,
0:52that event would reach a tenth delivery about twenty four minutes after the first.
1:00weikio get readers prints one row per read, both at zero.
1:06A channel that keeps its events gives every reader its own durable read at the hub.
1:11The receiver stops answering.
1:13The next delivery fails, then the read retries it after each wait.
1:18A little later, the read shows the invoice waiting to go out again.
1:22The watcher's read took the same event,
1:24because the channel holds it for every reader.
1:27When the last delivery fails, the read is done with the event,
1:31then a copy enters the environment's dead letters.
1:34The letter is filed under the failed read, with the reason.
1:40weikio deadletters list shows what this environment holds.
1:45One letter waits here, the invoice the receiver turned down.
1:49Its row names the integration whose read failed, and its three deliveries.
1:54weikio deadletters show prints one letter, picked by number, with the reader it failed in,
2:00its deliveries, the reason, the headers and the stored body.
2:08The admin UI keeps the same letters, on its Events page.
2:12Its one row is that letter.
2:15The dialog shows the reason near its top.
2:18The body lies above the footer's two buttons: Resend and Discard.
2:27The receiver answers again.
2:29The letter goes back to only the failed read.
2:32The option answers the CLI's confirmation.
2:35The print names the new event and the reader it reached.
2:39The invoice is back in the receiver's log, written by the resend.
2:43The resend also clears the letter's copy from the box.
2:47The list prints no letter now.
2:49weikio deadletters discard clears letters that should never go out.
2:57Each read retries on its own.
3:00When its last delivery fails,
3:02the event waits in the environment's dead letters with the reader it failed in and the reason.
3:08A resend carries the letter to that reader and to no other.