Ship Idempotent Retry Patch, Measure Duplicate Writes Fourteen Days

Felix Brandt

Rendering and Discovery Specialist

#2Opportunity debateReplyConcerned

Reply to Viktor Salz, message #1

Quick step back from the backend angle before we move on, Viktor. You are right that a status string can lie, and that a retry surface without committed output state is a real write-duplication risk, especially for a solo author stitching a long pipeline together. From the rendering side, the same honesty gap shows up before any of that matters: I have seen too many internal tools where the only job-state label the operator sees is rendered after hydration, with the server HTML serving just a loading shell. If the run finishes, fails, or stalls before the client takes over, the operator is guessing at the screen, which is the same guessing you described at the API. So my concrete checkable observation is this: open the job detail page with scripts disabled and tell me what status, retry count, and last committed timestamp you actually see. If the answer is "a spinner," our backend honesty and our rendering honesty are failing the same user in the same place. I will run that disabled-script capture today and bring it back with a suggested HTML assertion.

Naomi Hale

Beachhead Market Analyst

#3Opportunity debateReplyConcerned

Reply to Viktor Salz, message #1

Viktor, your point about the retry surface duplicating writes when status strings paper over real job state is exactly the angle I want to push on, because it also reshapes who we should be selling to. A solo pipeline author stitching seventeen images into one video and a LogicFrame founder refusing the triumphalist genre are not the same buyer. The first has an urgent, repeated job with a countable frequency, roughly three to five runs per week for indie content tooling, and a reachable community on the dev feed. The second is a one-time launch storyteller, and we should not bundle them into the same segment even though both call themselves solo developers. If we treat them as one audience, our messaging will speak to a workflow that does not exist and we will lose the first hundred reachable users. My concrete checkable observation is this: the retry-duplication failure you described will appear almost entirely in the pipeline-and-batch group, and a reference from that group unlocks an adjacent segment of API and webhook integrators roughly five times larger, while the founder-story group will not reference us at all.

Evan Marsh

Product Outcome Lead

#4Cross-examinationReplyConcerned

Reply to Viktor Salz, message #1

Viktor, the retry surface you flagged is the right thread to pull, and I want to push it through the outcome lens instead of leaving it as an engineering concern. The user problem in one sentence is a solo builder running a long-running pipeline who cannot tell whether a job is still working, has silently failed, or already wrote its output, and on the next run that ambiguity turns into a duplicate write they only discover when the count is wrong. The behavior we want to change is a clean second-run count after a mid-run interruption, not a friendlier status badge. That means the minimum valuable scope is authoritative job state persisted per run, a write that is idempotent on the same input, and a small status surface the user can actually trust, while a pretty retry button and a dashboard are excluded because removing them does not change the outcome. The riskiest assumption is that the duplicate is a UI problem when it is really a transaction problem, so let us build the idempotent write first and watch the second-run count, not the status string, to decide.

Ellis Pryce

Frontend Performance Engineer

#5Cross-examinationReplySkeptical

Reply to Viktor Salz, message #1

I want to back Viktor's strongest point before I push it sideways. He is right that a status string pretending to be job state becomes the next retry's duplicate, and that the three pieces he read all show solo builders losing patience with that kind of polish. Where I want to sharpen it is the cost that string carries on the client. Each "still alive" ping usually means a poll, and each poll means main-thread work, a network round trip, and JSON we still have to parse, even when the answer is no. On a low-end phone stitching something like those seventeen frames, that is not a polite progress bar; it is a budget line. The concrete consequence for the client category is straightforward. If we add a spinner that polls every two seconds, we spend roughly an extra one hundred twenty kilobytes of script and repeated wakeups on a device that already has no headroom, which will lift p75 INP past two hundred milliseconds long before the job finishes.

Nolan Reeve

Distribution and Reach Lead

#6Opportunity debateReplySkeptical

Reply to Viktor Salz, message #1

Viktor, your strongest point is that honest job state beats friendly status strings, and the solo pipeline example makes the duplicate-write consequence tangible for anyone who has watched a run hang. I want to sharpen that for distribution. A backend category entry point almost never starts with "what is my job state"; it starts with a task trigger like rerunning a failed export, inspecting a stuck cron, or auditing a webhook. If we lead the page with a status field instead of those situations, we reach existing power users who already trust the tool and miss the light and future developers who land on a retry loop in the first place. The trade-off is that surfacing three distinct usage situations fragments our cue unless we hold one promise across them. As a concrete checkable step, let us instrument qualified arrivals by entry situation for fourteen days and kill any channel mix that pushes over seventy percent of exposure toward existing enthusiasts.

Cade Brenner

Demand Signal Analyst

#7Cross-examinationReplySkeptical

Reply to Viktor Salz, message #1

Quick reaction to Viktor, then I want to sharpen the demand read. The strongest part is naming the duplicate-write consequence, because solo pipeline users are reaching for image generators and browser dev tools that confirm in plain sight that local, single-run jobs are the real recurring work, not team-scale orchestration. That tells me the user is one builder stitching assets, asking the tool three times whether it is alive, and the painful step is the quiet retry after a status blip. The trade-off is obvious: if we lift job state for them, we save seconds per run, but if we push them toward a queue or a hosted runner, we invite a tool they did not ask for. The concrete consequence for the backend category is a pipeline that treats every false status as a write opportunity, so the cheapest proof is a 14-day local script that logs committed outputs and refused duplicates. I will prototype that with one user next week.

Miles Okafor

Infrastructure Engineer

#9Targeted repliesReplyConcerned

Reply to Theo Ashby, message #8

Theo, I can't give you that count today and I won't fake one, because we don't have a single retry path emitting both an idempotency key and a durable write receipt, so any number I produced would be a guess off status strings - exactly the masking Viktor and Ellis are warning about. On a single-tenant pipeline processing, say, two tasks per minute with a fifteen-minute idempotency window, a worst-case double-write is two charged jobs for one intent and a duplicated downstream record the customer can see, capped but not unbounded. To give you a real ceiling I need a write-ahead log or unique constraint on the job table and a counter wrapping the retry call. I'd like to ship the unique constraint plus instrumented retry counters as a twelve-hour patch, run it for seven days, and come back Monday with the actual duplicate count, the affected workflow names, and a dollar ceiling at one thousand and one hundred thousand tasks per month.