agenciapsilmno/Obsidian/Brain/wiki/Migracao Schema-per-Tenant.md

Migração Schema-per-Tenant

Status: F5 concluída e testada E2E via HTTP (2026-06-13). Próximo: F6 (rewrite funções + migração de dados + drops). F0-F2 em main; F3+/F1b/F5 no branch até cutover.

F5 — entregue (commit 6b542cd) — PRIMEIRO teste real via HTTP do PostgREST

• postgres NÃO é superuser neste stack → não consegue ALTER ROLE authenticator. Quem consegue: supabase_admin (superuser, conecta com senha postgres via psql -U supabase_admin -h 127.0.0.1).
• database-novo/manual/f5_pgrst_refresh_schemas.supabase_admin.sql (aplicar como supabase_admin, fora do db.cjs): public.refresh_pgrst_schemas() (SECDEF owned supabase_admin) deriva a lista de tenant_schemas, seta pgrst.db_schemas in-database na role authenticator, NOTIFY pgrst reload config/schema. Expõe/retira schema SEM restart; a GUC persiste em pg_db_role_setting (sobrevive a stop/start) e SUPERSEDE o config.toml em runtime.
• migration 20260613000002: trigger em tenant_schemas (AFTER INSERT/DELETE/UPDATE, statement-level) dispara o refresh → clone_tenant_template e drop_tenant_schema NÃO precisaram ser tocados.
• config.toml (gitignored): baseline public, graphql_public + comentário; in-db config supersede.
• E2E via curl: clone → pgrst.db_schemas inclui tenant_x → GET /rest/v1/patients com Accept-Profile: tenant_x retorna 200 (vs 406 pra schema inexistente); drop → volta 406. Tudo sem restart de container. Primeira validação real do stack F1-F5 pelo caminho HTTP do PostgREST.

Gotcha F5

• PostgREST in-database config (db-config ligada por padrão, sem PGRST_DB_CONFIG=false): ALTER ROLE authenticator SET pgrst.db_schemas + NOTIFY pgrst, 'reload config' é a via pra schemas dinâmicos sem restart. reload schema sozinho NÃO adiciona schema novo à lista exposta — só recarrega o cache dos já expostos.

F4 — entregue (branch, commit 9b21642)

• _shared/tenant.ts: helper das edge functions — adminClient() (service_role/public), tenantDbForId(admin, tenantId), schemaForTenant, listTenantSchemas (crons varrem todos), resolveTenantByChannel (webhook→tenant via channel_routing), tenantSchemaName
• _shared/whatsapp-hooks.ts refatorado: hooks de tabela tenant recebem tdb; RPCs de crédito (deduct/add_whatsapp_credits) + tenant_members continuam em supa+p_tenant_id
• 23 edge functions migradas. Categorias:
  • inbound (twilio/evolution): tenant_id da URL → tdb
  • crons de fila (process-notification/email/sms/whatsapp-queue): varrem listTenantSchemas e drenam a fila de CADA schema — consequência direta da Q3 (filas viraram per-tenant). Modo single-tenant se body.tenant_id vier.
  • crons reminders/checks (send-session-reminders, conversation-sla-check, whatsapp-heartbeat-check, convert-abandoned-intakes, sync-email-templates): loop por tenant
  • routing por tenant_id (send-whatsapp-message, send-session-reminder-manual, twilio-provision, de/reactivate-channel, twilio-webhook): tenantDbForId; channel-actions sem tenant_id varrem schemas por channel_id (O(n) tenants)
  • asaas-*: tenant_id do body → tdb; asaas-webhook fica global
  • notification-webhook (Meta Cloud API): resolve via channel_routing por phone_number_id, fan-out por message_id quando não casa
• caller useAgendaEventLifecycle.js passa tenant_id pro send-session-reminder-manual (evento vive no schema)
• Sem deno local → validado por grep (zero tenant_id em cadeias tdb, clients todos declarados, imports batem). Type-check real só no deploy.

⚠️ DECISÃO PENDENTE — roteamento anon-por-token (bloqueia F5/F6)

Fluxos anônimos identificam o tenant por TOKEN/SLUG, não por login, então não sabem o schema: save-intake-progress (lê patient_intake_requests por token), intake RPCs (get-intake-invite-info, submit-patient-intake), AgendadorPublicoPage+RPCs do agendador (link_slug), document share links (validate_share_token, sign_document_by_token). Opções:

• A Índice global public_access_tokens(token_hash→tenant_id) + triggers de sync (O(1), +1 tabela global + triggers)
• B RPCs SECURITY DEFINER que varrem schemas pelo token (sem tabela nova, O(n) por request)
• C Manter as tabelas anon-facing (patient_intake_requests, patient_invites, document_share_links, agendador_configuracoes/solicitacoes) em PUBLIC com RLS por token — sidesteppa o problema; custo: essas não ganham isolamento físico (mas são as menos sensíveis, feitas pra acesso anon)

F3 — entregue (branch feat/schema-per-tenant, migration 07)

• src/lib/supabase/tenantClient.js (tenantDb(), tenantSchemaName()) + src/composables/useTenantDb.js
• tenantStore: getters activeTenantSlug/activeTenantSchema; my_tenants() RPC agora devolve slug+name (migration 20260612000007)
• codemod scripts/codemod-tenant-db.py: supabase.from('<84 tabelas + 6 views tenant>') → tenantDb().from(...) em 139 arquivos (777 chamadas), removeu 173 .eq('tenant_id') de cadeias tenant
• 4 agentes (2 ondas) fizeram a passada manual: tenant_id fora de payloads/selects/.or/.is; onConflict ajustado (singletons → 'singleton'); realtime de tabelas tenant aponta pro activeTenantSchema; repos dropam tenant_id defensivamente de payloads de callers externos
• descoberta importante: ZERO embeds cross-schema — todos os FK embeds são tenant→tenant (mesmo schema, ex. agenda_eventos→patients,insurance_plans) ou global→global (profile_specialties→profiles). O attachProfiles/fake-embed do blueprint NÃO é necessário aqui.
• gotcha: AGENDA_EVENT_SELECT (constante de select) tinha tenant_id — selecionar coluna inexistente quebra PostgREST; varrer constantes *_SELECT, não só .from()

Pendências F3 (fora do escopo, cross-tenant/anon → tratar em F4/F6)

• AgendadorPublicoPage.vue — scheduler público anon, resolve tenant por link_slug (precisa RPC/edge de resolução slug→schema, igual channel_routing)
• Saas{Feriados,NotificationTemplates,DocumentTemplates,Whatsapp}Page.vue — gerenciam defaults do sistema (tenant_id NULL) ou views cross-tenant; após F6 devem mirar _tenant_template ou channel_routing. Continuam apontando pra public (funcional até o drop da F6).

F2 — entregue (migration 20260612000006)

Os 3 únicos pontos de criação de tenant (provision_account_tenant, create_clinic_tenant, ensure_personal_tenant_for_user — este último também acionado pelo trigger de signup handle_new_user_create_personal_tenant) agora chamam clone_tenant_template() na mesma transação: clone falhou → tenant não nasce. Smoke: ensure_personal criou tenant pessoal tenant_terapeuta_pessoal com 84 tabelas + registro, 2ª chamada idempotente, drop limpou tudo. Não há fluxo de exclusão de tenant no sistema (drop_tenant_schema fica pra uso admin/manual).

F1 — entregue (migrations 20260612000001–05 em database-novo/migrations/)

• tenants.slug criado + backfill dos 9 + trigger auto-gera/imutável
• Helpers: tenant_schema_name/for, tenant_id_for_schema, tenant_schema_checked(p_tenant_id) (valida is_tenant_member — substitui current_tenant_schema do blueprint)
• _tenant_template: 84 tabelas sem tenant_id, 6 singletons (singleton boolean PK/UQ nas configs 1-linha: company_profiles, email_layout_config, conversation_autoreply_settings/bots/sla_rules, session_reminder_settings), 4 sequences locais, 94 FKs (62 intra + 32 pra public/auth), 6 views com placeholders __SCHEMA__/__TENANT_ID__ em _views, seeds de sistema (whitelist 8 lookups)
• clone_tenant_template(uuid) → tabelas+seqs+seeds+FKs+views+RLS (policies com tenant_id EMBUTIDO: is_tenant_member('<uuid>') + saas_admin_full)+realtime+grants+trigger routing+registro em tenant_schemas
• drop_tenant_schema(uuid) protegido; public.channel_routing (webhook inbound acha tenant do canal) sincronizada por trigger
• Smoke: clone tenant_smoke_f1 → 84 tabelas/168 policies/roundtrip/routing sync/singleton rejeitando 2ª linha → drop limpo

Gotchas aprendidos na F1

• postgres não é superuser no Supabase → session_replication_role proibido; seeds usam retry-loop de FK (rounds). Vale pro F6 (migração de dados): rodar como supabase_admin ou retry-loop.
• db.cjs aplicava migration sem ON_ERROR_STOP → rollback silencioso reportado como sucesso. Corrigido (psqlFile agora usa -v ON_ERROR_STOP=1).
• Linhas operacionais órfãs com tenant_id NULL (intakes/convites/notifs) NÃO são seeds — whitelist explícita.
• Clones F1/F2 ainda SEM triggers de negócio (F6) e fora do PostgREST (F5) — _meta.triggers_pending=true.

Migração de multi-tenant RLS-only (tenant_id em cada tabela) para schema físico por tenant (tenant_<slug>), seguindo blueprint do projeto irmão (novo-rumo.txt na raiz), adaptado.

Artefatos

• docs/F0_categorizacao.md — varredura completa: classificação das 137 tabelas, 66 funções, 6 views, FKs, edge functions, divergências.
• novo-rumo.txt (raiz) — blueprint original com lições do projeto irmão.

Números-chave

• 137 tabelas public → 79 tenant-scoped + 5 em decisão (infra mensageria) + 53 globais
• 66 funções afetadas (blueprint avisava: listas pré-feitas subestimam — era "29" lá, 66 aqui)
• 1 única FK global→tenant problemática: whatsapp_credits_transactions.conversation_message_id
• 0 policies de tabelas globais usando funções a refatorar
• 9 tenants (3 clínicas + 6 therapists), volumetria minúscula (<400 linhas/tabela)

Divergências vs blueprint (decisivas)

1. Sem tenants.slug — precisa criar coluna ou usar uuid no nome do schema.
2. Multi-membership: profiles.tenant_id 100% NULL; verdade vive em tenant_members (4 users multi-tenant). current_tenant_schema() do blueprint não funciona → frontend escolhe schema (tenantStore já tem activeTenantId), segurança via policy com tenant_id embutido por schema + RPCs recebem p_tenant_id validado com is_tenant_member().
3. 6/9 tenants são terapeutas individuais — schema por signup; custo operacional do config.toml do PostgREST cresce com tenants.
4. email_layout_config.tenant_id e email_templates_tenant.tenant_id apontam pra auth.users (legado) — mapear na migração de dados.
5. View current_tenant_id é código morto (claim JWT nunca populado).

Decisões (2026-06-12)

• Q1: criar tenants.slug → schemas tenant_<slug>
• Q2: todo tenant ganha schema (clínicas e therapists)
• Q3: mensageria tenant-scoped (isolamento máximo, contra rec. global) → crons varrem tenants em loop; webhooks inbound precisam de índice global channel_routing (channel_external_id → tenant_id) pra rotear antes de gravar
• Q4: asaas tenant (staging asaas_webhook_events global roteia)

Total final: 84 tabelas tenant-scoped, 53 globais.

Fases (tasks #1–#7 na sessão)

F0 categorização ✅ · F1 template+helpers · F2 provisionamento · F3 frontend useTenantDb · F4 edge functions · F5 PostgREST config · F6 rewrite funções + migração dados + drops (lotes, backup antes de cada um)

Relacionados: Decisões de Billing da Agenda, Supabase Local, index