fix: record the user_hackathons migration on main (#254) - #255
Merged
Jose-Gael-Cruz-Lopez merged 1 commit intoAug 10, 2026
Merged
Conversation
public.user_hackathons exists in the live Supabase project — table, RLS policies and grants — but nothing on main said so. The migration that creates it lived only on the unmerged draft branch for #236, and main's migrations stopped at 20260722192614. That left the repo drifting from the database in two directions at once: rebuild a database from main's migrations and you get a schema missing a table production has, and the migration is absent from supabase_migrations.schema_migrations, so a future `supabase db push` would try to replay a create table for a table that already exists. Bringing the file onto main independently of #236, because the drift is not contingent on that feature landing. The migration is idempotent against the live database — `create table if not exists`, every `create policy` preceded by `drop policy if exists`, and the grants, revokes and `enable row level security` are all no-ops on a re-run — so recording it here changes nothing about the running system. Also brings the README section documenting the divergence, which the migration header already points at ("See README for the divergence") but which only existed on the same draft branch. It records that this file was applied through the SQL Editor rather than `apply_migration`, why `ls` returns one more entry than the recorded ledger, and how to reconcile if a CLI is ever wired up. Deliberately does NOT bring 20260810064325_atomic_tracker_upsert.sql. That one defines a function only tracker-store.ts calls, which exists on #236's branch alone; landing it here would add a function nothing on main uses. This does not by itself apply anything to the database. The table is already there, so main and production now agree — but the ledger reconciliation described in the README is still outstanding if a CLI is adopted. Closes #254 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
hackhq | 68ed90f | Commit Preview URL Branch Preview URL |
Aug 10 2026, 06:52 AM |
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.
Closes #254.
public.user_hackathonsexists in the live Supabase project right now — table, RLS policies, grants — but nothing onmainrecorded that it does. This lands the migration that creates it, plus the README section explaining why it's a special case.The drift
The migration lived only on the unmerged draft branch for #236;
main's migrations stopped at20260722192614. That left the repo disagreeing with the database in two directions:main. Rebuild a database frommain's migrations and you get a schema missing a table production has.supabase_migrations.schema_migrations, so a futuresupabase db pushwould try to replay acreate tablefor a table that already exists.Why land it separately from #236
The drift isn't contingent on that feature merging. #236 is still a draft and blocked behind a Clerk↔Supabase dashboard configuration (#235); the repo shouldn't keep misdescribing the database until that resolves.
This changes nothing about the running system
The migration is idempotent against the live database, so recording it here is inert:
create table if not exists public.user_hackathonscreate policydrop policy if existsalter table … enable row level securitycomment on tablegrant/revoke(×4)Also included
The README section documenting the divergence. The migration header already points at it — "See README for the divergence" — but that section only existed on the same draft branch, so on
mainthe reference dangled. It records that the file was applied through the SQL Editor rather thanapply_migration, whylsreturns one more entry than the recorded ledger, and how to reconcile if a CLI is ever adopted. The README change is purely additive: 27 insertions, 0 deletions.Deliberately not included
20260810064325_atomic_tracker_upsert.sql, the atomic-upsert fix from #236. It defines a function onlytracker-store.tscalls, and that file exists on #236's branch alone — landing it here would add a function nothing onmainuses. It stays with the PR that needs it.Still outstanding after this
This does not reconcile the ledger.
mainand production now agree about what exists;supabase_migrations.schema_migrationsstill has no row for this version. If a Supabase CLI or MCP is ever wired up, that reconciliation — insert the version, or re-run throughapply_migrationagainst a fresh database — is still needed, and the README now says so.🤖 Generated with Claude Code