FIELD NOTE / TIKTOK
Make retry safety survive every agent run.
The short film, the complete written thought, and the evidence behind it.
The TikTok edition will be linked here after its public post is verified.
Make retry safety survive every agent run.
Day 01 · 2026-09-28 · TikTok
Short video caption
A fresh idempotency key after an ambiguous timeout is an ordinary retry mistake that junior developers and lighter agent runs may miss. Give every route a shared gateway that persists one key per checkout intent. Stripe may prune keys after 24 hours, so later retries need reconciliation before any new charge command. In trusted CI, drop the acknowledgment after capture, retry, query provider and order ledgers by intent, and require a deliberately broken key variant to fail. Simulated case; Stripe documents idempotent retries and retention limits. #EricFieldNotes
Full written post / accessible read
Agentic coding can move checkout work fast. A junior developer or lighter agent run may mint a fresh idempotency key for each retry. That is a familiar engineering mistake, not some exotic AI failure. At agent speed, the same missing pattern can return in every new payment route.
In this simulated run, the provider captures seventy-nine dollars. Its response disappears before the application sees it. The app retries with a new key. The provider sees a second command and captures again. The browser still shows one confirmed order; the customer sees two charges.
Give feature code one payment gateway. Persist the checkout intent and key before the first call; reuse that key on an ambiguous retry. Include the intent ID in provider metadata so you can find orphaned captures. Stripe may remove a key after twenty-four hours, so a later retry needs provider reconciliation before another charge command. Keep new routes off direct provider calls.
Now make the harness drop the acknowledgment after capture, retry, and compare every provider capture for that intent with the order. Change the retry to mint a new key on purpose; the test must turn red. Do this because a rule in a markdown file cannot prove what a payment provider actually did.
#EricFieldNotes
Runnable illustrative contract: commerce harness
Evidence and boundary
On-screen boundary: SIMULATED RETRY · KNOWN PATTERN. The sources below support documented mechanisms and specifications; illustrative scenarios are not presented as measured incidents.