Summary
Since Supabase CLI 2.110.0 bumped the bundled realtime image from supabase/realtime:v2.112.6 to v2.113.4, realtime.messages is owned by supabase_realtime_admin and DDL against it is mediated by the supautils policy_grants allowlist.
That allowlist appears to permit CREATE POLICY and DROP POLICY on realtime.messages, but not COMMENT ON POLICY on a policy the caller just successfully created. As postgres on a fresh local stack, the COMMENT fails with 42501 insufficient_privilege.
This breaks migration replay for anyone who documented their realtime.messages broadcast RLS policy with a COMMENT: the CREATE POLICY succeeds and the immediately following COMMENT ON POLICY aborts the migration.
Repro
On a fresh local stack, as postgres:
CREATE POLICY my_broadcast_read
ON realtime.messages
FOR SELECT
TO authenticated
USING (realtime.topic() = 'demo:' || (select auth.uid())::text);
-- CREATE POLICY (succeeds)
COMMENT ON POLICY my_broadcast_read ON realtime.messages IS 'per-user broadcast read';
-- ERROR: permission denied for table messages
-- SQLSTATE: 42501
supabase stop --no-backup && supabase db reset
Observed
| CLI |
bundled realtime |
CREATE POLICY |
COMMENT ON POLICY |
2.109.1 |
v2.112.6 |
OK |
OK |
2.110.0 |
v2.113.4 |
OK |
42501 |
The change is visible in the tag diff (v2.109.1...v2.110.0): -FROM supabase/realtime:v2.112.6 / +FROM supabase/realtime:v2.113.4.
Question
Is the exclusion of COMMENT ON POLICY from the policy_grants allowlist intentional, or an oversight?
If policy DDL on realtime.messages is meant to stay open to postgres for user-defined broadcast RLS, it seems inconsistent that a policy can be created and dropped but not documented. If it is intentional, it would help to have that called out in the release notes, since it is a silent migration-replay break for anyone whose existing (already-applied) migrations comment their policies.
Current workaround is to wrap the COMMENT in a DO $$ ... EXCEPTION WHEN insufficient_privilege THEN RAISE NOTICE ... END $$; guard and pin the CLI to 2.109.1.
Environment
- Supabase CLI
2.110.0 (regression) vs 2.109.1 (last good)
- Local stack via
supabase start / supabase db reset
- Docker Desktop, Windows and
ubuntu-latest GitHub Actions runners (same behaviour on both)
Summary
Since Supabase CLI
2.110.0bumped the bundled realtime image fromsupabase/realtime:v2.112.6tov2.113.4,realtime.messagesis owned bysupabase_realtime_adminand DDL against it is mediated by the supautilspolicy_grantsallowlist.That allowlist appears to permit
CREATE POLICYandDROP POLICYonrealtime.messages, but notCOMMENT ON POLICYon a policy the caller just successfully created. Aspostgreson a fresh local stack, theCOMMENTfails with42501 insufficient_privilege.This breaks migration replay for anyone who documented their
realtime.messagesbroadcast RLS policy with aCOMMENT: theCREATE POLICYsucceeds and the immediately followingCOMMENT ON POLICYaborts the migration.Repro
On a fresh local stack, as
postgres:Observed
CREATE POLICYCOMMENT ON POLICY2.109.1v2.112.62.110.0v2.113.442501The change is visible in the tag diff (
v2.109.1...v2.110.0):-FROM supabase/realtime:v2.112.6/+FROM supabase/realtime:v2.113.4.Question
Is the exclusion of
COMMENT ON POLICYfrom thepolicy_grantsallowlist intentional, or an oversight?If policy DDL on
realtime.messagesis meant to stay open topostgresfor user-defined broadcast RLS, it seems inconsistent that a policy can be created and dropped but not documented. If it is intentional, it would help to have that called out in the release notes, since it is a silent migration-replay break for anyone whose existing (already-applied) migrations comment their policies.Current workaround is to wrap the
COMMENTin aDO $$ ... EXCEPTION WHEN insufficient_privilege THEN RAISE NOTICE ... END $$;guard and pin the CLI to2.109.1.Environment
2.110.0(regression) vs2.109.1(last good)supabase start/supabase db resetubuntu-latestGitHub Actions runners (same behaviour on both)