Repository navigation
[EN-1892] feat(db): migrate existing default team names to project naming - #3334
Merged
Kraci merged 5 commits intoJul 23, 2026
Merged
Conversation
Contributor
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
Contributor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bc0b23db25
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
Found 1 test failure on Blacksmith runners: Failure
|
❌ 3 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
tvi
approved these changes
Jul 23, 2026
Kraci
deleted the
migrate-existing-default-team-team-names-to-projects-en-1892
branch
July 23, 2026 15:24
ValentaTomas
added a commit
that referenced
this pull request
Jul 24, 2026
…3369) Two migrations merged today share the goose version `20260723120000` (`set_tier_max_disk_size` from #3350 and `rename_default_team_names_to_project` from #3334). Goose panics on duplicate versions at collection time, so since the second merge **every** goose invocation fails — all DB-touching test shards on every open PR, and any deploy-time migration step. Renumbers the later-merged one to `20260723172400` (its merge time). This is safe precisely because of the failure mode: no goose run since the collision could have applied it anywhere, so no environment has it recorded under the old version; the earlier migration keeps its number and its applied history. Flagging as the likely root cause of ARM64 test-shard failures on currently-open PRs (observed on #3368) and of any migration-step failures in deploys since 17:24Z.
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
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.

Why
Final part of the teams → projects rename stack (PR 1: dashboard copy + banner, PR 2: provisioning generator — merged). New signups now get "Personal Project" / "'s Project", but existing rows still hold the old generated names. This data-only migration renames those rows so existing users stop seeing stale "Default Team" naming in the dashboard.
What it does
Renames only the two exact forms the old generator (
provisioning/names.go) ever produced:Default Team→Personal Project(exact match)<Word>'s Default Team→<Word>'s Project(suffix-anchored)Customer-chosen names that merely contain the phrase (e.g. "My Default Team Stuff", "Best Team") are untouched. Slugs, IDs, memberships, API keys, and every other column are unchanged — verified that
team_slug_triggerfiresBEFORE INSERTonly, so a nameUPDATEcannot regenerate slugs.Safety design
(id, old_name)rows are snapshotted into_backup_teams_default_team_renamein the same transaction as the update. Exact restore is a singleUPDATE … FROM(documented in the migration); a follow-up migration drops the table after a soak period.RAISE NOTICEd into migrator logs.Verified locally against Postgres 16 with the real slug trigger: six seed cases (bare, possessive, mid-string, "Best Team", name==email, unrelated) — only the first two change, second run is a no-op, and the restore drill from the backup table reproduces the original state exactly.
Pre-merge gates (do not merge until checked)
_backup_teams_default_team_renameafter soakKnown accepted non-effects: billing/Stripe keep the provisioning-time name on historical invoices; rows where name equals the user's email stay as-is (handled by the render-time transform from PR 1); mid-string stragglers remain by design.