[terencecho]

What

When a version create gets no answer and the saved request is later refused, Share can keep offering Try again for the same request. It now asks the person to check the review page, change the export settings, and export again. Desktop can show its existing export action, and a fresh render ID clears the old failure even if the file path is reused.

Why

A refusal of a replay does not establish the outcome of the earlier request. Keeping the original body and idempotency key avoids starting a second create for the same render while the first can still finish.

How

Show the recovery message for a refused replay when there is no more specific server guidance. A first-send snapshot mismatch still falls back to video-only.

Test plan

• Reproduced the generic retry loop with a 503 followed by repeated 422 snapshot mismatches.
• Verified the unchanged operation and snapshot on replay, the export action, failure reset when a new render overwrites the same path, and a successful new version under a new key.
• Verified first-send snapshot mismatch still falls back to video-only.
• All 57 share tests passed on Node 22. Share build, typecheck, lint and test reachability passed. The package fits the existing size budget.

[jrusso1020]

Reviewed at 8fd3cb473451c8c2763b7628bcef9b137739ebcb.

The recovery change preserves the pending request rather than treating a refused replay as proof that the original create never happened. failedSend leaves the original operation/body/snapshot intact for an unanswered create; the new guidance marks generic retry unavailable and exposes the existing export action. A first-send snapshot mismatch still falls back to video-only with a new operation key. Known reason-specific guidance and 401/408/429 handling retain precedence.

I verified the same-path recovery claim against source and tests: failure identity now includes the host's render ID, while persisted create identity still uses the source fingerprint and checksum. Changing only the render ID clears the displayed failure; identical bytes still reuse the pending operation. The new regression changes the exported bytes as well before expecting a fresh operation.

Validation on Node 22 through pytest-gate.sh: 57 share tests passed. Temporarily removing the refused-replay fallback makes the new regression fail with the old generic Try again message; restoring it gives 2/2 targeted recovery tests passed. The source was restored byte-for-byte. Full changed files and the host export-ID contract were read; independent adversarial review found no blocker. No live application/backend upload or published-package consumer run was exercised.

Need: yes · Size: focused recovery change · Reuse: existing versionSentence and export action contract · Simpler: preserves the existing pending-operation model · Structure: fine (checked bodyToSend, sendCreate, failure identity and versionSentence; no split)
Risk: medium - changes recovery presentation around persisted unanswered writes.

Verdict: APPROVE
Reasoning: The change gives actionable recovery without changing the uncertain create's idempotency contract, and the regression detects the original retry loop.

Reviewed by hf-review.