Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Round 3 follow-ups of the production deploy (#404): verify the promotion, rollback wording, split promotions, empty pair

Open
  • Is something wrong?
#406 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, typescript
Domain
ci-cd, devops

Research direction

Read docs/deployment-vercel.md section 7 and the deploy-production.yml workflow to understand the documented recovery path and promotion order. Then inspect dispatcher/src/snapshot/vercel-api.ts and the stage, canary, and promote jobs; add tests for production verification and rejecting empty pairs on rebuilds. Done means all four follow-ups are addressed, tests cover the new checks, and the rollback and split-promotion guidance matches the workflow.

Written by the indexing model from the issue text.

Description

Follow-ups from round 3 of the review of #404 (production deploy via GitHub Actions and Infisical). The review's verdict was "safe to merge and run"; these four are P3.

Review: https://github.com/ExpidetGames/code-reviewer/pull/404#issuecomment-6233048046

1. The way out of rollback_snapshot_missing is a revert commit, not a manual run

docs/deployment-vercel.md (section 7, and the allow_stale input description in deploy-production.yml) says to "deploy the old commit as a new run (a manual run with allow_stale)". A workflow_dispatch run always has GITHUB_SHA equal to the head of main, so allow_stale only matters when main moves during the run; "Re-run all jobs" of an old push run has empty inputs and is refused by fresh. What works is a revert commit on main (a normal run), or a re-run of an old dispatch run that had allow_stale set.
Fix: change the sentence in section 7 (and the input description) to the revert commit, or drop the input.

2. Verify after vercel promote that production actually moved

In CLI 64.5.0 a vercel promote can exit 0 without production having moved: "No deployment promotion in progress", "Promote deployment was skipped", and the 202 "queued behind a rolling release". The jobs then go green, persist writes the pair and record writes "Promoted to production." while the old deployment still serves.
Fix: after vercel promote, ask the API (the code for it exists in dispatcher/src/snapshot/vercel-api.ts: livePair, productionDeployment) whether targets.production.id of the project is the staged deployment's id, and fail the promote job if it is not, before persist and record. Add a shell/unit test. It matters most on the first run, where promote has never run on the platform.

3. An App/Dispatcher split when main moves between the two promotions

If main moves between promote-app and promote-dispatcher, the freshness check in promote-dispatcher fails after the App is already out. The next run completes both, but the window can be a whole build, and a release that changes the runner API is exactly the case where the App must come first and the Dispatcher must follow.
Fix, one of: check freshness once before promote-app and let promote-dispatcher go on (the App is already out); or state this case in the "pipeline stopped between the two promotions" row of section 7.

4. The || fallback of the pair is fail-open if a rebuilding run's build outputs are ever empty

needs.snapshot-build.outputs.X || needs.snapshot-decide.outputs.X is right when the build is skipped. When rebuild == 'true' the decide outputs are empty by design, so an empty build output would stage a Dispatcher with no --env, run a canary with no expectation (empty snapshot_id and image_digest mean "do not check") against the project's old pair, and promote. No path was found that produces empty build outputs, but closing it is cheap.
Fix: a step in stage-dispatcher and in canary, or an if, that requires a non-empty pair whenever snapshot-decide.outputs.rebuild == 'true'; with a test.

Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
1h 19m
Merged PRs (30d)
328

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ExpidetGames/code-reviewer

All issues in ExpidetGames/code-reviewer

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.