ci(e2e): grant service_role table access after loading schema.sql

The backend queries exclusively as service_role (lib/supabase.ts, service key,
'bypasses RLS'). schema.sql revokes client grants (anon/authenticated) but
assumes a hosted Supabase where service_role already has full table access — on
a fresh CLI stack loaded via psql it gets none, so the first backend write 500s
with 'permission denied for table user_profiles' and every project/chat spec
fails. Granting service_role after the schema load reproduces the production
grant posture.

Verified in CI: POST /projects 500 -> 201, GET /chat 500 -> 200.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
QA Runner 2026-07-17 14:31:34 -07:00
parent d427cc2674
commit 9daee40542

View file

@ -113,6 +113,19 @@ jobs:
# schema file already includes the latest shape, so no migrations are # schema file already includes the latest shape, so no migrations are
# replayed on a fresh CI database. # replayed on a fresh CI database.
psql "$DB_URL" -v ON_ERROR_STOP=1 -f backend/schema.sql psql "$DB_URL" -v ON_ERROR_STOP=1 -f backend/schema.sql
# schema.sql revokes client grants (anon/authenticated) on purpose, but
# it assumes a HOSTED Supabase project where service_role already holds
# full table access. On a fresh CLI stack loaded via psql, service_role
# gets no grants on the newly-created public tables, so the backend —
# which queries exclusively as service_role (lib/supabase.ts) — 500s with
# "permission denied for table user_profiles" on the first write. Restore
# the production grant posture so the API behaves as it does in prod.
psql "$DB_URL" -v ON_ERROR_STOP=1 <<'SQL'
GRANT USAGE ON SCHEMA public TO service_role;
GRANT ALL ON ALL TABLES IN SCHEMA public TO service_role;
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO service_role;
GRANT ALL ON ALL FUNCTIONS IN SCHEMA public TO service_role;
SQL
- name: Wire env from Supabase - name: Wire env from Supabase
run: | run: |