Dead letter queue
A message that cannot be delivered is not dropped. It goes into the dead letter queue, is retried on a schedule, and stays visible until it either succeeds or is given up on deliberately.
Why it exists
The bearers this product uses fail in ways ordinary networks do not. A satellite pass ends mid-send. A modem loses its fix. A mesh neighbour walks behind a hill. None of those mean the message was wrong; they mean the moment was. Discarding it would be the wrong answer, and so would retrying it forever at full speed.
What is kept
| Field | Meaning |
|---|---|
payload | the message itself, stored whole |
retries / max_retries | attempts so far, and the ceiling, three by default |
next_retry | when it becomes eligible again |
status | pending, or the terminal state it reached |
last_error | why the last attempt failed |
priority | 0 critical, 1 normal, 2 low |
Priority
Priority exists because the queue can drain over an expensive bearer. When a pass is short and the queue is long, an SOS should not wait behind a telemetry sample. Entries are selected by priority first and next_retry second, which is what the index on (priority, next_retry) is for.
Giving up
After max_retries an entry stops being retried and stays in the queue with its last error, so somebody can see what happened. It is not deleted automatically: a message that failed is evidence, and on this product it may be evidence about somebody's safety.