verify-migration.sh: treat lagging target sequences as a failure, not a warning
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
Research direction
Start in verify-migration.sh, section 9 (SEQUENCES), especially the logic around lines 566-579, and trace how blocking checks contribute to the script exit status. Verify the behavior with a target sequence behind the source: it should emit a failure and return non-zero instead of only warning. Confirm that non-lagging sequences retain their current passing behavior.
Written by the indexing model from the issue text.
Description
In verify-migration.sh, section 9 (SEQUENCES) compares last_value for each sequence between source and target. When a target sequence is behind the source, it only emits log_warn and increments SEQ_BEHIND — but SEQ_BEHIND is never wired into the script's exit code (it only gates the log_pass line, ~verify-migration.sh:566-579).
Impact: an operator running verification before cutover sees a yellow warning, not a failure. If target sequences lag the source (e.g. they were never reset after CDC), the target will hand out already-used IDs after cutover — duplicate-key errors on first writes. Verification should stop this, but currently doesn't.
Proposed change: make a lagging sequence (SEQ_BEHIND > 0) a hard failure with a non-zero exit, consistent with the other blocking checks in the script.
Context / why now: the underlying pgcopydb gap — sequences not being reset after a resumed CDC follow — is fixed in planetscale/pgcopydb (sequence reset on pgcopydb follow reaching endpos). This issue is defense-in-depth: even with that fix, verification should fail loudly if sequences are ever stale, so a future regression can't slip through to cutover.
- Dominant language
- Shell
- Stars
- 32
- Forks
- 9
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from planetscale/migration-scripts
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
planetscale/migration-scripts#26 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 38/100
All issues in planetscale/migration-scripts
Similar issues
-
docs(agents): strengthen the no-backslash-escaped-backticks rule with an issue-creation example Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
package-update
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
oSoWoSo/vOid_Community_repOsitory#148 · 1 comment ·
-
chore
Difficulty 1/5 Under an hour Newbie friendliness 91/100
alunduil/alunduil-chezmoi#792 ·
-
area: compat bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
zenhub-dev
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
OpenLiberty/ci.docker#747 ·