test:db (job obrigatório invariants) reprova em conjunto e passa isolado — gate por sorteio

[melgarafael]

Medido na main 38888ba, durante a triagem do lote #188–#201.

O defeito

pnpm test:db (o job obrigatório invariants) reprova em arquivos que passam quando rodados
sozinhos. Os 82 arquivos de invariante compartilham um Postgres, e o resultado depende de com quem
cada um dividiu o banco.

Rodada cheia, na main 38888ba:

$ pnpm test:db
 Test Files  2 failed | 80 passed (82)
      Tests  2 failed | 578 passed | 1 skipped (581)      EXIT=1

 FAIL tests/invariants/followup-engine.test.ts
   × trigger → end leva 2 ticks (1 avanço de nó por tick)
     AssertionError: expected +0 to be 1
 FAIL tests/invariants/followup-reactivity.test.ts
   × marca next_eval_at=now + wake marker; o TICK do engine classifica…
     AssertionError: expected 0 to be greater than or equal to 1

Os mesmos dois arquivos, isolados, no MESMO commit:

$ pnpm test:db tests/invariants/followup-engine.test.ts tests/invariants/followup-reactivity.test.ts
 Test Files  2 passed (2)
      Tests  20 passed (20)                                EXIT=0

Não é contenção de máquina. As falhas são AssertionError sobre valores de negócio (contagem de
ticks, marcador de wake), não Test timed out — a assinatura de sobrecarga é outra e eu a vi
separadamente nesta mesma sessão, em test:unit, com 10 timeouts e 4 workers que nem subiram.

Já apareceu antes, em outro par

Na triagem do #200, o mesmo padrão com tests/invariants/agent-send-template-turn.test.ts:
AI_NoSuchToolError: … unavailable tool 'send_template' na rodada cheia, verde isolado. Na época eu
não abri issue porque não reproduzi numa rodada limpa — a explicação chata (contenção) explicava o
que eu tinha. Agora reproduziu num par diferente, com assinatura de asserção, e não explica mais.

Por que importa mais do que "teste instável"

invariants é check obrigatório na branch protection. Um gate que passa ou reprova por sorteio:

1. bloqueia merge legítimo — e o caminho de menor resistência vira "roda de novo até passar", que
   é como um gate deixa de significar alguma coisa;
2. deixa passar regressão de verdade — se a ordem foi favorável, o vermelho que importava não
   aparece. O CI da main neste mesmo commit ficou verde enquanto eu media vermelho localmente.

O segundo é o caro: o gate de isolamento multi-tenant é justamente este.

NÃO MEDIDO

• O mecanismo. "Passa isolado, falha em conjunto" é compatível com poluição de estado no banco
  compartilhado e com dependência de ordem/tempo. Não isolei qual, e não vou afirmar o que não medi.
• Qual arquivo contamina qual. Não fiz bisseção de ordem.
• Se o CI reproduz. No CI o invariants passou neste commit; a diferença pode ser ordem, paralelismo
  ou carga. Um --sequence.shuffle no CI provavelmente exporia — e é o primeiro experimento que eu faria.

Aceite sugerido

• identificar o mecanismo (estado compartilhado × ordem), com bisseção
• tornar cada arquivo de invariante hermético — fixture por arquivo, ou truncate no beforeAll
• rodar com ordem embaralhada no CI, para o defeito parar de depender de sorte

[melgarafael]

Terceira medição, e ela fecha a caracterização: o mesmo código dá resultados diferentes.

#	árvore	resultado
1	main 38888ba (rodada cheia)	`2 failed
2	os mesmos 2 arquivos, isolados, no mesmo commit	20 passed, exit 0
3	main + #202 (rodada cheia, 85 arquivos)	**`614 passed

A rodada 3 é a que fecha o argumento. Não é "esses dois arquivos estão quebrados" — é que o
resultado depende da rodada. Entre a 1 e a 3 entraram arquivos novos (82 → 85), o que muda a
ordem e a vizinhança de cada um no banco compartilhado, e o vermelho sumiu sem ninguém consertar nada.

Isso importa para a priorização: um gate obrigatório cujo veredito muda com quem entrou na suíte não
está medindo o que diz medir. E o modo perigoso não é o vermelho falso — é o verde falso, quando a
ordem favorável esconde a regressão que o gate existia para pegar. O de isolamento multi-tenant está
nesta suíte.

Continua não medido o mecanismo (estado compartilhado × ordem), pelo mesmo motivo de antes: não
fiz bisseção. O experimento mais barato continua sendo rodar com --sequence.shuffle algumas vezes e
ver se a taxa de vermelho sobe.

[melgarafael]

Quarta medição, e ela fecha o caso pelo lado que faltava: o experimento que a issue pedia foi feito, e o resultado é pior do que "reprova em conjunto".

1. O experimento pendente (--sequence.shuffle.files), enfim rodado

Régua: origin/main f9abedd; tests/invariants/, supabase/baseline.sql, scripts/test-db.sh e vitest.db.config.ts byte-idênticos ao main (git diff --stat origin/main HEAD -- <eles> sai vazio). Suíte: 100 arquivos, 720 casos.

ordem default          Test Files 100 passed (100)   EXIT=0
seed=101               Test Files 100 passed (100)   EXIT=0
seed=202               Test Files 1 failed | 99      EXIT=1
seed=303               Test Files 1 failed | 99      EXIT=1
seed=404               Test Files 1 failed | 99      EXIT=1

Taxa de vermelho: 3 em 4. O vitest imprime Running tests with seed "N", então uma rodada vermelha do CI é reproduzível — o que hoje não é possível, porque a ordem default não é anunciada.

2. O achado que muda a caracterização: nem a ordem default é estável

A tabela acima é de uma máquina. Na minha, mesmo SHA, mesma suíte, ordem default:

$ TEST_DB_PORT=54399 pnpm test:db
 Test Files  1 failed | 99 passed (100)
      Tests  711 passed | 1 expected fail | 8 skipped (720)
 FAIL  tests/invariants/gov-6-assignee-kind.test.ts

E numa terceira máquina, também em ordem default, quem caiu foi gov-1b-team-manager-read.

Três execuções do mesmo código, na mesma ordem nominal, com três vítimas diferentes — incluindo "nenhuma". Ou seja: "default" não é uma ordem do repositório, é o que aquele processo resolveu naquele momento. A issue dizia "reprova em conjunto e passa isolado"; o que se mede agora é que o veredito não é função do código.

3. A causa, com a mensagem do banco

psql: ERROR: insert or update on table "user_organizations" violates foreign key
constraint "user_organizations_organization_id_fkey"
DETAIL: Key (organization_id)=(eeeeeeee-0000-4000-8000-000000000002)
        is not present in table "organizations".
 ❯ tests/invariants/gov-6-assignee-kind.test.ts (7 tests | 7 skipped)

Não é flake de tempo nem de carga: é estado global compartilhado. vitest.db.config.ts diz textualmente que todos os arquivos batem no MESMO Postgres, com fileParallelism: false, e os arquivos compartilham namespaces de UUID fixos (cccccccc-…, eeeeeeee-…) sem ninguém limpar no fim. Quem roda depois encontra a org que o vizinho apagou — ou não encontra a que ele esperava criar.

Note o 7 skipped: o beforeAll estourou e os 7 casos não rodaram. Um arquivo que não roda soma como "não falhou" em quase toda leitura apressada do relatório.

4. Por que isto é mais grave do que um gate chato

O modo perigoso não é o vermelho falso, é o verde falso: a ordem favorável esconde a regressão que o gate existe para pegar. E o invariants é o job que carrega rls-isolation — o teste de isolamento multi-tenant, que o CLAUDE.md declara obrigatório antes de merge. Um gate cujo veredito é sorteado não prova isolamento; ele produz um carimbo.

5. O conserto tem um bloqueio de processo, e a decisão é sua

A causa proximal é endereçável em ~8 linhas: dar namespace de UUID próprio a cada arquivo (o c1c1c1c1- está livre — grep -rc em tests/invariants/ não acha uso). Mas isso é modificar arquivo em tests/invariants/**, e loop/hooks/freeze-invariants.sh bloqueia status M/D/R ali sem DESKCOMM_GOV_INVARIANTS_EDIT=1.

O hook diz o que fazer nesse caso: "Invariante incômodo = ou o código está errado, ou o invariante está mal-escrito — o segundo caso vai pra inbox, não pro Edit." Este é o segundo caso. Não exportei a env por conta própria e não escrevi na loop/INBOX.md porque o loop de governança não está rodando — a caixa não teria leitor. O achado fica aqui, que é onde você olha.

Duas coisas para decidir: (a) destravar o congelamento para este conserto; (b) se, depois dele, vale ligar --sequence.shuffle.files=true no job. Sobre (b) há uma ressalva medida: --sequence.shuffle.tests (dentro do arquivo) derruba 14–18 arquivos e não é o mesmo defeito — vários it() são narrativa sequencial por desenho. Ligar o shuffle inteiro trocaria um problema por outro; só shuffle.files corresponde ao que se quer garantir.

Não medido

• Se renomear os namespaces basta. O vitest.db.config.ts documenta um acoplamento de ordem entre playbook-seed e agent-no-credential que nenhuma renomeação de UUID resolve — precisa ser medido sob as seeds 202/303/404 depois do conserto, antes de ligar qualquer shuffle no CI.
• Quantos dos 100 arquivos deixam estado para trás. Não fiz o inventário.

[melgarafael]

Corrigido no PR #242 — e o conserto não precisou tocar em tests/invariants/**.

A causa, com prova direta

Não era só "estado compartilhado": era estado compartilhado + on conflict do nothing sem arbiter, que transforma colisão em silêncio em vez de erro. Duas instâncias reais:

human-cases.test.ts:39            SESSION_A    = cccccccc-…-0003, provider waha
agent-send-template-turn.ts:54    SESSION_META = o MESMO uuid,    provider meta_cloud

Quem chega depois não cria nada e não reclama. Se human-cases roda antes, o provider fica waha, loadChannelProvider devolve waha, o motor apaga a tool send_template — e 4 asserções caem dizendo "o template não saiu", com o produto certo. Idem colisão de slug entre gov-1b e gov-6.

Rodando os dois arquivos em sequência num banco fresco, sem reset entre eles:

$ vitest run human-cases.test.ts                → 9 passed
$ vitest run agent-send-template-turn.test.ts   → 4 failed | 1 passed
    AI_NoSuchToolError: Model tried to call unavailable tool "send_template"
$ (com o reset por arquivo, MESMO banco sujo)   → 5 passed

O conserto mora no harness, não nos invariantes

loop/hooks/freeze-invariants.sh bloqueia M/D/R em tests/invariants/**, e o próprio hook diz que invariante mal-escrito vai para a inbox, não para o Edit. Então o isolamento passou para onde não há congelamento: o baseline é aplicado uma vez num banco-molde (inv_baseline) e cada arquivo recebe uma cópia nova (create database postgres template inv_baseline, ~0,2s), por um setupFile de vitest.db.config.ts.

Renomear UUID arquivo a arquivo consertaria as duas instâncias. O molde conserta a classe — nenhuma fixture nova pode reintroduzi-la. E com isso o --sequence.shuffle.files=true entrou no próprio script: a ordem deixa de ser acordo tácito e passa a ser exercitada a cada run.

Medido, com o script real, nas três seeds que eram vermelhas

ANTES (a8b09280)          DEPOIS
seed 202 -> EXIT 1        seed 202 -> EXIT 0   Test Files 101 passed (101)
seed 303 -> EXIT 1        seed 303 -> EXIT 0   Test Files 101 passed (101)
seed 404 -> EXIT 1        seed 404 -> EXIT 0   720 passed | 1 expected fail | 1 skipped

Sabotagem (remover o setupFile): 2 arquivos caem — a colisão original volta e o arquivo-guarda novo morde. É o par que mostra que o crédito está no lugar certo.

Custo — o par de números discordantes, com rótulo

A contabilidade do vitest diz +22,8s de setup em 101 arquivos (~0,23s/arquivo, +20% de wall-clock). Mas as rodadas da loteria levavam 153–155s contra ~161s do conserto: um arquivo que estoura no beforeAll "termina" rápido. O gate ficou ~5% mais lento e passou a medir o que diz medir.

Isto destrava a #236

Dois invariantes inserem o mesmo meta_phone_number_id=111 em orgs diferentes, o que hoje impede criar a UNIQUE que aquela issue pede — medido lá: os dois índices propostos deixavam o invariants vermelho. Com o banco por arquivo, a colisão deixa de existir e a trava do banco fica aplicável.