fix(clickhouse): renumber the external deployment id migration to 041 - #4734
Conversation
|
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. 💤 Files selected but had no reviewable changes (1)
⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
040 was already claimed by 040_create_task_events_search_v2.sql (#4615) by the time #4661 landed, so `goose up` panics with "duplicate version 40 detected" while collecting the migration directory and applies nothing. Renumber this one rather than the other: goose keys on the version number and not the filename, so version 40 is already recorded wherever 040 has been applied, and renaming that file would re-run an applied migration. This one has never been applied anywhere, because collection aborts before any SQL runs.
b31a02a to
336fd5c
Compare
@trigger.dev/build
trigger.dev
@trigger.dev/core
@trigger.dev/python
@trigger.dev/react-hooks
@trigger.dev/redis-worker
@trigger.dev/rsc
@trigger.dev/schema-to-json
@trigger.dev/sdk
commit: |
Summary
goose upagainstinternal-packages/clickhouse/schemapanics onmaintoday, so ClickHouse migrations cannot be applied from a fresh checkout. Renumbering the external deployment id migration from 040 to 041 clears it.Root cause
Two migrations claim version 40. #4615 added
040_create_task_events_search_v2.sql, and #4661 added040_add_task_runs_v2_external_deployment_id.sqla day later. #4661 was opened before #4615 merged, so 040 was genuinely free at branch time, and because the two files have different names there is no textual conflict for git or a rebase to surface. Both merged green, and no workflow in this repo runsgoose, so the collision only shows up the first time someone actually migrates.goose parses the numeric filename prefix as the version and refuses duplicates:
It aborts while collecting the directory, before executing any SQL, so nothing was half applied and there is no migration state to repair.
This migration gets renumbered rather than the
task_events_search_v2one because goose keys on the version number and not the filename: version 40 is already recorded wherever 040 has been applied, so renaming that file would re-run an applied migration.Verified with a full
goose upagainst ClickHouse 26.2.19.43 (the image pinned ininternal-packages/testcontainers): migrations apply cleanly through version 41, andtask_runs_v2.external_deployment_idlands asString DEFAULT ''.