Queue the pre-roll for API-created campaigns too - #282
Merged
Merged
Conversation
Queueing the render lived only in the dashboard server action, but that is not the only way a campaign is created. The public API at /api/ads/v1/campaigns goes through createCampaignForUrl in lib/ads/campaigns.ts, and that is how myna and the rest of the automation file ads. Every automatically created campaign therefore got its display creatives and no video, and nothing anywhere said so — the campaign simply had no pre-roll, forever. It showed up as a campaign created at 15:27 today, after the backfill, sitting with six design creatives and no render job while every backfilled campaign had one. Moves the call into the shared creator so both paths are covered by construction rather than by remembering. Same rule as the trending promo grant directly below it: a render is an extra output of creating a campaign, never a precondition for one, and queueCampaignVideo returns null on every failure rather than throwing. 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.
Queueing the render lived only in the dashboard server action. That isn't the only way a campaign gets created.
The public API at
/api/ads/v1/campaignsgoes throughcreateCampaignForUrlinlib/ads/campaigns.ts— which is how myna and the rest of the automation file ads. So every automatically created campaign got its display creatives and no video, and nothing anywhere said so. The campaign simply had no pre-roll, forever.How it surfaced
Auditing coverage after the backfill finished, four product campaigns had no render job. One of them:
Release myna 0.35.0 · profullstack/mynaposterCreated after the backfill ran, by automation, through the API — six creatives and no video, while every backfilled campaign had one. The other three are duplicate designs whose render deduped onto a twin campaign's job, which is the cache working as intended.
The fix
Move the call into the shared creator, so both paths are covered by construction rather than by remembering to add it in two places.
Same rule as the trending promo grant immediately below it: a render is an extra output of creating a campaign, never a precondition for one.
queueCampaignVideoreturnsnullon every failure rather than throwing, so a rendering outage still can't fail an API campaign creation.Verification
2551 passed / 1 failed repo-wide — the pre-existing
tracker-geofailure (mmdb not installed locally). Root and worker typechecks clean.Backfill is complete as of this PR: 174 of 174 product campaigns rendered, zero failures, 229 MB of assets.