Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to design note puts the only safe boundary for a transactional SMS receipt in an immutable intent carrying one idempotency key, at the price of making template retention and privacy-aware storage the application's problem.
The Engineer · Build desk
build
A Timed-Out Reset SMS Is Not A Failed One, And Your Retry Code Probably Disagrees1 distinct publisher
build
The OTP send-storm is an admission bug: cooldowns belong in the transaction, not the countdown1 distinct publisher
build
Claude Code walks the whole process table to inherit one shell's environment1 distinct publisher
build
Four Clocks, One Timeout: Why Long-Audio Transcription Needs a State Machine1 distinct publisher
Compiled by The EngineerSomething wrong?How this is made
A client-side timeout is a local event. The deadline expires, the read unwinds, and the caller has learned exactly one thing: that it stopped waiting. According to the dev.to post, that is the entire content of the signal, and it does not establish whether the transport accepted the message [3]. The remedy it proposes is to stop collapsing four independent facts into one status column, namely that the payment settled, that the application recorded a notification intent, that a transport accepted an attempt, and that the recipient's network reported an outcome. None of the four implies the next [5].
The design puts durability ahead of cleverness: the database write that acknowledges the payment-settlement event is meant to be the same write that creates the outbox record, because a crash between two writes leaves either an acknowledged event with no receipt or a receipt with no durable record of why it exists [9]. Uniqueness is enforced on the event identity or on a deterministic key such as `order_receipt:<payment_event_id>` [8]. Everything after that is a compare-and-set against a locked row; the post notes that an Express service can apply the same transition after loading the intent under a row lock, and that the language is incidental while the persisted boundary is not [15].
Count the enum in the sketch and you get six states, two of them terminal, and exactly one that may open a new transport attempt [1]. `submitting` is where the work happens: it holds an unresolved attempt and must be polled, not resent [6]. That only functions if the provider accepts a caller-supplied idempotency key and can be asked about one specific prior attempt. Where it cannot, `submitting` has no exit except a timer, and the model degrades into a slower version of the guess it replaced.
Content immutability is the other half. Rendering is treated as a pure function of `(template_version, render_data)`, validated before the intent becomes dispatchable, with a content fingerprint recorded and transport metadata kept out of the business payload, which is also what stops a status webhook or poller from acquiring permission to alter receipt content [14]. The intent names a version rather than a mutable alias such as `latest`, so a retry hours later cannot re-read a changed cart, a corrected product title, or a template deployed since [11].
Mapping a dozen provider delivery labels at the adapter is unglamorous work, and it is the only reason order processing never has to learn what your carrier means by its own vocabulary [7]. The post is disciplined about what all of this buys: a place to contain ambiguity, short of exactly-once delivery [10]. A duplicate at the carrier remains possible; what the design removes is the second receipt your own code would have created after reading a timeout as a failure [3][16].
Ranked by verification strength, evidence, and original report placement.
An order receipt is evidence of a settled payment, so the sending process cannot be allowed to reinterpret the order or quietly render a newer template after a timeout.
The application should own an immutable receipt intent containing order ID, payment-settlement event ID, recipient, template version, render data, and one idempotency key.
A client-side timeout says only that the caller stopped waiting; it does not establish whether the transport accepted the message, so a timeout means unknown outcome rather than failed delivery.
The post's short answer: persist the receipt intent before dispatch, reuse its idempotency key for every retry, poll the same attempt after an ambiguous response, and permit a new send only after the state machine reaches a terminal retryable outcome.
Four facts are often collapsed into one status string: the payment settled; the application recorded a notification intent; a transport accepted an attempt; the recipient's network reported a delivery outcome. None implies the next.
The state machine is narrower than the provider vocabulary: pending may dispatch; submitting has an unresolved attempt and must be polled, not resent; accepted may still need status polling; delivered and permanent_failure are terminal; a bounded retryable_failure can return to pending while preserving the same logical idempotency key.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 1, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One author, but checkable by reading
The strength here is that you do not have to trust the writer: the six-state machine, the unique constraint on the payment event, and the timeout-versus-failure distinction are all inspectable arguments, and the Python sketch either holds together or it doesn't. The weakness is that nobody else is in the room — no gateway documentation, no incident report, no second engineer describing the same duplicate-receipt failure in production.
No sign of it running anywhere
Nothing in this reporting places the pattern in a live payment path. No SMS provider is named, no service is said to have shipped it, and there is no duplicate-receipt count before or after. The one worked example — worker A timing out on order_receipt:pay_157, worker B resolving attempt 1 — is written as an illustration, and the code beside it is by the author's own statement not a provider client.
Sized below its own reach
This note argues against itself more often than for itself. It declines the exactly-once framing, lists version retention and privacy-aware storage as burdens it is handing you, and tells promotional senders to keep their templates elsewhere. Set against that restraint, one word overreaches: retryable_failure is called bounded, and the bound never arrives — no attempt limit, no backoff, no expiry for the poller that is left holding the entire timeout case.
Nothing on sale
No gateway is named, no product is positioned, and the author keeps invented endpoints out of the code on purpose — an unusual amount of restraint for a piece about messaging infrastructure. What pull remains is the ordinary gravity of a developer-platform post: a clean six-state model reads better than the messy real provider contract that would blur its edges, and the note quietly leaves that contract offstage.
Trust the reasoning, not the result
As a design argument this holds: a compare-and-set on a durable row, one idempotency key reused across attempts, and an outbox record written in the same transaction as the event acknowledgement are all standard and internally consistent here. What cannot be trusted yet is the outcome — that following this prevents a second receipt for a settled payment. Nobody in this reporting has run it, and the states where it would be tested are exactly the ones left unparameterised.