Summary
config.validate_required() accepts SUPABASE_KEY on its own, so the backend
starts cleanly with only the anon key. Every Supabase write then runs as anon
and is refused by row-level security, and the failures surface one endpoint at
a time rather than at startup.
Why it matters
dependencies/auth.py states the assumption the rest of the backend is built
on:
The backend talks to Supabase with the service role key, which bypasses
Row Level Security.
When that assumption does not hold, nothing says so. The operator sees inserts
failing against a correctly applied schema, and the natural next step is to
loosen the RLS policies — which is how a permissive-policy workaround gets
written. (Two such files were in backend/; #1 removes them.)
Suggested change
In config.validate_required(), keep the current requirement, and log a
warning when SUPABASE_SERVICE_ROLE_KEY is absent while SUPABASE_KEY is set
— naming what will fail (chat history, profiles, community persistence) and
pointing at the variable that fixes it.
A warning rather than a hard failure, so that anyone deliberately running the
read-only surface without the service-role key is not locked out.
Alternative
Make the service-role key required outright. Stronger, but it turns a currently
working configuration into a boot failure, so it seemed like your call rather
than mine.
Happy to open a PR if the warning approach looks right.
Summary
config.validate_required()acceptsSUPABASE_KEYon its own, so the backendstarts cleanly with only the anon key. Every Supabase write then runs as
anonand is refused by row-level security, and the failures surface one endpoint at
a time rather than at startup.
Why it matters
dependencies/auth.pystates the assumption the rest of the backend is builton:
When that assumption does not hold, nothing says so. The operator sees inserts
failing against a correctly applied schema, and the natural next step is to
loosen the RLS policies — which is how a permissive-policy workaround gets
written. (Two such files were in
backend/; #1 removes them.)Suggested change
In
config.validate_required(), keep the current requirement, and log awarning when
SUPABASE_SERVICE_ROLE_KEYis absent whileSUPABASE_KEYis set— naming what will fail (chat history, profiles, community persistence) and
pointing at the variable that fixes it.
A warning rather than a hard failure, so that anyone deliberately running the
read-only surface without the service-role key is not locked out.
Alternative
Make the service-role key required outright. Stronger, but it turns a currently
working configuration into a boot failure, so it seemed like your call rather
than mine.
Happy to open a PR if the warning approach looks right.