Arnas Donauskas 95faf58e75 fix(ai): grant EXECUTE on claim_ai_reply_slot so auto-reply works (#345) ... Migration 029 created claim_ai_reply_slot(uuid, integer) as SECURITY DEFINER but never GRANTed EXECUTE — the only function in the schema missing its grant (007/012/017/018/019/025/030 all grant theirs). SECURITY DEFINER sets the privileges a function runs *with*, not who may *call* it: the caller still needs EXECUTE. On instances where the default PUBLIC execute privilege on public-schema functions has been revoked (hardened / self-hosted Supabase), the service_role that PostgREST uses cannot invoke it. The AI auto-reply path runs entirely under the service-role client (the inbound webhook has no auth.uid()), so db.rpc('claim_ai_reply_slot') fails permission-denied, the dispatch bails before sending, and the bot silently never answers ANY inbound message. The Playground works because it never claims a slot — matching the report. - 031_ai_reply_slot_grant.sql: new migration granting EXECUTE to service_role (029 is already applied on existing installs, so it needs its own migration to reach them). service_role only — the sole caller — matching the 007/012 increment-counter precedent. - 029_ai_reply.sql: add the same grant next to the definition so fresh installs are correct. - auto-reply.ts: log a real claim RPC error instead of returning silently, so this class of deploy failure is diagnosable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>		2026-07-07 10:43:03 +03:00
..
migrations	fix(ai): grant EXECUTE on claim_ai_reply_slot so auto-reply works (#345)	2026-07-07 10:43:03 +03:00