install.sh/update.sh: o mesmo SUPABASE_DB_URL faz o DDL e o runtime do app

[melgarafael]

Achado e descrito por @ygorebos, instalando numa VPS com Supabase self-hosted. Ele o deixou
registrado como fora do escopo do PR #188; eu confirmei no código da main 9249e6f e abro aqui
para não se perder — o fork dele foi apagado e o PR fechou junto.

O que ele descreveu

install.sh e update.sh usam o mesmo SUPABASE_DB_URL para instalar schema e para o app rodar.
São necessidades diferentes: create extension e o baseline.sql exigem o dono do banco, enquanto
o app quer a role menor. Num Supabase da nuvem isso não aparece porque a connection string do
pooler já é privilegiada; self-hosted obriga a trocar a role antes e depois, na mão.

Confirmado no código

Uma variável, dois papéis:

papel	onde
DDL — aplica baseline.sql, cria extensões, promove o dono	install.sh:1175, :1190, :1196, :1208, :1218, :1243; update.sh:129, :134
runtime do app — vai para o .env que os contêineres leem	install.sh:1067 (envq SUPABASE_DB_URL "$SUPABASE_DB_URL")

E o projeto já recomenda a separação em outro lugar — docs/deploy-selfhost/README.md:76:

Crie também a role dedicada do worker (mais seguro que usar o superusuário):

create role agent_worker login password 'TROQUE-ESTA-SENHA' bypassrls;

Então a doutrina escrita e o instalador discordam: o doc manda separar, o install.sh não tem onde
receber a segunda role.

Por que não aparece na nuvem

Na nuvem a connection string do Session pooler já é postgres.<ref>, privilegiada o bastante para as
duas coisas. O acoplamento existe lá também — só não dói. Num Supabase próprio, dói na primeira
instalação, e a saída hoje é editar o .env na mão entre uma etapa e outra.

Encaminhamento sugerido (não é decisão minha)

Duas variáveis, com a de DDL sendo opcional e caindo na outra quando ausente — assim a nuvem não muda
nada e o self-host ganha o encaixe:

• SUPABASE_DB_URL — a do app (a role menor)
• SUPABASE_DB_ADMIN_URL — a do schema; se vazia, usa a de cima

Se for por aí: a var nova entra em .env.example e em lib/env.ts como opcional (§5 do
complemento-do-ci.md), e o update.sh precisa da mesma distinção — ele reaplica o baseline.sql.

NÃO MEDIDO

Não instalei numa VPS com Supabase self-hosted para ver a falha acontecer. O que eu confirmei foi o
acoplamento no código e a recomendação conflitante no doc; o relato da falha em campo é do @ygorebos.

[melgarafael]

Procede, e há um achado que muda o caminho do conserto. Medido em origin/main f9abedd.

Uma variável, dois papéis — confirmado:

DDL:      install.sh:1360 (create extension), :1375, :1381, :1393 (aplica o baseline),
          :1403, :1428 (promove o dono);  update.sh:129, :133
Runtime:  install.sh:1238 — envq SUPABASE_DB_URL "$SUPABASE_DB_URL"   (a MESMA string vai pro .env)

Não existe segunda variável (git grep SUPABASE_DB_ADMIN_URL → vazio, com controle positivo na mesma sonda), e o runtime não precisa de DDL: git grep por create|alter|drop (table|index|extension) em lib/ app/ workers/ devolve nada, com controle positivo em pool.query. O app só faz DML.

O aviso que economiza um PR: a correção intuitiva — pôr SUPABASE_DDL_URL="${SUPABASE_DB_ADMIN_URL:-$SUPABASE_DB_URL}" no _common.sh — quebra o kit inteiro e o check obrigatório verify. Medido aplicando literalmente numa cópia:

SUITE EXIT=1   OK=0   FAIL=0
./_common.sh: linha 7: SUPABASE_DB_URL: variável não associada

(controle: a mesma cópia sem o patch dá EXIT=0 OK=161)

Causa: o _common.sh é sourced antes do load_env (install.sh:704 vs :710; update.sh:12 vs o enter_project que chama load_env), e ele abre com set -euo pipefail — a variável ainda não existe. E mesmo com guarda (${SUPABASE_DB_URL:-}) o valor congela vazio enquanto o real chega depois, o que faria os 8 sítios de DDL rodarem psql "".

Ou seja: a separação tem de acontecer depois do load_env, não no topo do arquivo compartilhado. Deixo a issue aberta com essa restrição registrada, para quem pegar não gastar o PR descobrindo isso.