Repository navigation
fix(stack): apply roles.sql once and as postgres (CLI-3130) - #7595
Conversation
CLI benchmark (Lightweight Commands): no changes foundCommit
API calls: unchanged for all 8 commands. Binary size: 135.0 MB, unchanged. Details: timing ranges, API calls per command, slowest phasesTiming ranges
API calls per command
Slowest phasesNo command moved beyond noise, so there are no phase deltas. Comment |
There was a problem hiding this comment.
🤖 AI Review
Both independent reviews completed with no findings. Inspection of the diff and surrounding code confirmed the overlay lifecycle, postgres credentials and ownership, webhook refresh, and shadow-cache invalidation. No actionable issues or fundamental conflicts with the pending next-branch work were found. Tests were inspected but not executed.
Findings
No issues found.
Stats
Claude findings: 0 · Codex findings: 0 · Confirmed: 0 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
jgoux
left a comment
There was a problem hiding this comment.
Looks good: the overlay now runs once on first setup as postgres, later starts still reapply webhooks, and the shadow cache key bump drops baselines built under the old owner.
TL;DR
fixes the stack replaying
supabase/roles.sqlon a later start and running it assupabase_adminwhat's missing?
adding or dropping a service between starts ran
roles.sqlagain, so a plaincreate rolefailed withrole "…" already existsit also ran as
supabase_admininstead ofpostgres, so a migration using a schema fromroles.sqlfailed withpermission denied for schemanow fixed by?
the stack runs it once on first setup, as
postgres, like the legacy backendvisual rep
ref: