Retry a failed render instead of returning the failure forever - #285
Merged
Merged
Conversation
Dedupe is keyed by a hash of the design, and the reuse branch handed back whatever row it found — including a failed one. So the first failure became a permanent verdict on that copy: re-saving the campaign produced the same hash, found the same failed row, and queued nothing. The render card's advice to edit and save to try again was advice that could not work, because an unedited campaign hashes identically. This surfaced immediately after the animated banner bug: three good pre-rolls had been failed by a broken GIF encode, and with that fixed and deployed the campaigns still would not render, because the failed rows were being handed straight back. A failed row is now requeued and re-enqueued, capped at three attempts. The cap matters because the failure may be deterministic — a snapshot this renderer cannot draw — and the row is keyed by design rather than by attempt, so without one every save of an unrenderable campaign would queue the same doomed work again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan48 finding(s) HIGH/CRITICAL: 2 | MEDIUM: 31 | LOW: 15
Snippets are redacted; ThreatCrush never prints matched credential material. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A failed render was a permanent verdict on a design.
Dedupe is keyed by a hash of the design, and the reuse branch handed back whatever row it found — including a
failedone. So the first failure stuck forever: re-saving the campaign produced the same hash, found the same failed row, and queued nothing.The render card's own advice — "Editing the campaign queues a fresh attempt" — could not work, because an unedited campaign hashes identically. I wrote that line believing it.
How it surfaced
Immediately after the animated-banner frame-pattern bug. Three good pre-rolls had been failed by a broken GIF encode; with that fixed and deployed, the same campaign still wouldn't render:
Queued nothing. The fix was live and unreachable.
The change
A failed row is requeued and re-enqueued, capped at three attempts.
The cap matters: the failure may be deterministic — a snapshot this renderer simply cannot draw — and the row is keyed by design rather than by attempt, so without a cap every save of an unrenderable campaign would queue the same doomed work again, forever.
Verification
Two tests: a failed job below the cap is requeued with its
error_codecleared; at the cap it is returned as-is with no write. 2565 passed / 1 failed repo-wide — the pre-existingtracker-geofailure. Typechecks clean.After this deploys I'll re-queue the canary and confirm three GIFs actually land, then look at them before reporting the feature as working.