Be explicit whether retry reuses the original parameters or allows the request to be edited

What it is

After hand-off, people face a choice: send the same request again, or change the conditions and then send. These are not one button. Original-parameter retry covers “that attempt did not get through”. Edit-then-retry covers “that attempt would never have succeeded” — a bad query, a file too large, an unsupported format, a filter too tight. The UI must say which of the two this next send will be. A vague Retry must not carry both meanings.

Why it happens

The failure reason splits parameters into “still valid” and “already condemned”. Timeout, 502: parameters are likely still valid; sending the same payload is right, editing is a tangent. 400, 422, format rejected: the same payload will be rejected again; original-parameter retry is spinning, and people need to return to an editable demand. When both collapse into one button, people cannot predict what the tap will do: will filters drop, must the file be re-picked, will the words being typed be cleared. Failed prediction makes people afraid to tap, or tap and find context reset.

Being explicit also protects idempotency. Original-parameter retry should carry the same idempotency key: “still that attempt”. Edit-then-retry is a new demand and should change the key, or the other side will treat the new content as a duplicate of the old submit and drop it. Split the meaning on the UI, and the keys can be split correctly.

Where it stops holding

A pure list-fetch with nothing to edit only has original-parameter retry; do not invent an “edit” for symmetry. When there are many parameters but the failure is unrelated to them (site-wide 503), sending people to change filters is shifting blame; original-parameter retry is the act, changing filters is another act. Partial-success batches (twenty files, five failed) must say in that batch’s context whether retry is the failed subset as-was, or whether two can be dropped first; the default is usually the failed subset as-was. Automatic retry is always original parameters; editing can only happen in human hands after hand-off.

Applying it

• Transient failure: primary action labelled “try again”, sends the original request and key, does not reset the form.
• Parametric failure: primary action returns to editable, copy names which field to change; do not offer a same-again retry that will fail as the primary button.
• When both are tenable, primary is original parameters, secondary is “edit and retry”. Do not fuse them into one control.
• How to check: one timeout, one 422. Timeout retry should fire as-was with the form still there; 422’s primary should let people change a field. If both screens share one Retry and the 422 re-sends the original JSON, the meanings were not split.

Related

• Same group: I2.13.1 Automatic retries need backoff; immediate tight retries pile onto the server · I2.13.2 After several automatic retries fail, stop and hand the decision to the person · I2.13.4 A pattern of repeated failure suggests a systemic problem, not a flaky network blip
• Nearby: I2.08 Load failure · I3.05 Idempotency and duplicate submit · I2.06 Cancel during wait
• Search terms: retry same request · edit and retry · idempotency key