fix: re-apply the two migrations that share a version

[skabou]

20260815140000_assignment_parent_session.sql (#52) and 20260815140000_roster_revoke_anon_read.sql (#48) were written on parallel branches and landed with the same version prefix.

Supabase records an applied migration by that timestamp as its unique id, and migration list compares only timestamps. So once 20260815140000 is recorded, the other file carrying it is treated as already applied and skipped — with no error and no output.

One of these two has therefore never run on any database built from this repo, and which one depends on when that database last migrated:

• assignment skipped → assignments.parent_session_id is missing and the dashboard's parent/child session grouping breaks. Loud, easy to spot.
• revoke skipped → anon/authenticated still hold select on roster_students, which carries adaptations — the free-text column the UI solicits IEP and accommodation notes into.

The second is the one that matters, and it fails silently. That grant is inert today only because RLS is enabled with no policies, which denies everything — a fail-closed accident, as the original migration's own comment says. It stops being inert the first time anyone adds a permissive policy, which is the natural next step when teacher auth arrives. At that point it becomes a public read of the whole roster through the client-visible anon key.

Why forward-only rather than renaming

#62 renamed both files to fresh versions. That works, but rewrites migration history that is already deployed. This adds one new migration instead and touches nothing existing.

Every statement is idempotent — add column if not exists, create index if not exists, and revoke (revoking a privilege that was never granted is a no-op in Postgres). So it is a no-op on a database where both already applied, and a repair on one where either was skipped.

Checking which state you are actually in

Not required before merging — the migration is safe either way — but if you want to know:

-- was the version recorded, and by which?
select * from supabase_migrations.schema_migrations where version = '20260815140000';

-- did the column land?
select column_name from information_schema.columns
where table_name = 'assignments' and column_name = 'parent_session_id';

-- is the grant still there? (rows here mean the revoke did NOT run)
select grantee, privilege_type from information_schema.role_table_grants
where table_name = 'roster_students' and grantee in ('anon', 'authenticated');

Not verified locally

There is no Docker on this machine, so I could not stand up a local Supabase and reproduce the skip. The mechanism is from the Supabase documentation, not from observation; supabase db reset on a machine with Docker would confirm both the problem and this fix.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
interactive-learning-experiences	Ready	Preview	Aug 15, 2026 7:43pm