The outbox relay's missing integer: how one unsendable row stalls the whole pipeline

A developer publishing on dev.to ran an outbox relay between two services and wrote up the failures, and the first one is a two-line loop that every version of the pattern online implies but nobody prints ^[2]. The pattern as usually stated is four sentences: write the event in the same transaction as the row, poll the table, send to Kafka, mark it sent ^[1]. The relay that implements it claims a batch of unsent rows, sends each one, and marks it SENT on a broker ack ^[3]. The first version of the loop caught exceptions, logged that the row stays NEW and will be retried, and then called `break` ^[4]. That `break` is not sloppiness. It is there so that per-partition ordering survives a failure: if row 3 cannot be sent, rows 4 through 20 must not overtake it ^[5]. On its own the choice is correct. What is missing is an integer. Nothing counts how many times row 3 has already failed ^[6]. If the cause is permanent rather than transient, which the author lists as a broker that is genuinely down for that topic or a payload the producer cannot serialize, the relay retries that same row on every poll forever, and every row behind it accumulates behind a jam that will not clear by itself ^[7]. There is no ceiling and no signal; the only symptom is a NEW count in the table that keeps rising ^[8]. Ordering preservation and unbounded retry compose into an unbounded backlog: the block never ends, and every subsequent insert for that partition joins it ^[23]. The repair is an attempts column read, incremented, and compared against a maximum ^[9]. Past the limit, which defaults to 10, the row is written to status FAILED with its attempt count ^[10][11]. The important detail is that the give-up path uses `continue`, not `break`, so the jam the dead row was causing clears while the rows behind it, which may still succeed, keep trying ^[12]. Rows that have not exhausted their budget still get `break` after their counter is persisted ^[13]. Bounding retries this way also bounds the blast radius: a permanently unsendable row costs at most 10 failed sends before it is parked, instead of one per poll indefinitely ^[24]. The other half of the value is operational. A FAILED row is something a human can query, alert on, and replay by hand once the root cause is fixed; an infinitely retried NEW row surfaces nowhere ^[14]. That is the difference between a pipeline with a queue depth you can chart and one you have to notice. The uncomfortable part, in the author's telling, is that the counterless version passed every test that existed. The suite covered the happy path and a single transient failure that resolved itself ^[15]. Nothing covered "this row will never succeed", because writing that test requires first accepting that a message can be permanently unsendable, which is exactly the assumption the four-sentence version of the pattern encourages you to skip ^[16]. The same write-up flags a related gap: HTTP clients propagate trace context automatically, so a call from order into inventory carries the caller's trace ^[17], while a polled outbox row does not, because the originating request is long finished by the time the relay reads it and Kafka has no concept of a trace ^[18]. Left alone, each consumed event starts its own trace and the inventory hold appears in Jaeger as an orphan ^[19]. The author's fix is manual: a trace_id column written from MDC at insert time ^[20], re-attached by the relay as a Kafka header next to the dedup message id ^[21], and restored by the consumer before processing so logs and spans stay tagged ^[22].