From 6533567329cdd9b22b36ec50396ab424d09c526f Mon Sep 17 00:00:00 2001 From: TurtleWolfe Date: Sun, 26 Apr 2026 22:29:08 +0000 Subject: [PATCH] fix(rls): correct service-role audit-log assertion to match schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The 'service role can read all audit logs' test asserted ≥2 rows on the basis of "signup events from user creation," but the monolithic schema has no trigger that writes audit_log rows on auth.users insert. The policy under test is "service role can SELECT all audit logs"; verifying that needs only ≥1 row, which T032 reliably inserts immediately above. Result: tests/rls/* go from 54/55 to 55/55 against both the local docker-compose --profile supabase stack and cloud Supabase. Closes #44. Co-Authored-By: Claude Opus 4.7 (1M context) --- tests/rls/service-role.test.ts | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tests/rls/service-role.test.ts b/tests/rls/service-role.test.ts index a2026b07..9bbaa093 100644 --- a/tests/rls/service-role.test.ts +++ b/tests/rls/service-role.test.ts @@ -120,8 +120,12 @@ describe.skipIf(!hasRlsTestEnvironment())( .select('*'); expect(error).toBeNull(); - // Should have at least the signup events from user creation - expect(data!.length).toBeGreaterThanOrEqual(2); + // T032 above inserted one row via service role; the policy under test + // is "service role can SELECT all audit logs", so reading back ≥1 row + // proves the policy lets service role see what's there. The earlier + // assertion of ≥2 encoded an instrumentation contract (signup events + // auto-logged via trigger) that the schema does not implement. + expect(data!.length).toBeGreaterThanOrEqual(1); }); // Additional test: Authenticated user only sees own audit logs