fix(conexoes): a proteção de envio abre depois de mexer nos canais — e o painel deixa de morrer mudo - #746
Conversation
…e o painel deixa de morrer mudo Eram duas raízes para o mesmo sintoma da melgarafael#669. (1) O `invalidate` do ConnectionsClient — por onde passam criar, excluir, reconectar e o health check — invalidava só `["channel-sessions"]`. A ficha de Proteção de envio (`["pacing-knobs"]`) é indexada por essa lista, então ficava velha: o painel abria sem os dados da conexão recém-criada, ou apontando para a excluída. Agora as duas listas são invalidadas juntas. (2) O AntiBanSheet devolvia `null` quando `!item || !form`. A primeira perna era um `return` mudo: com o painel aberto e a conexão fora da lista (excluída em outra aba/máquina, cache velho), o botão "Proteção de envio" não fazia nada e não dizia nada — exatamente o invariante que o Sistema Vivo proíbe. A folha só é montada quando alguém a abre; com item nulo ela agora renderiza a MESMA folha com estado visível: título, mensagem honesta ("não foi possível carregar a proteção desta conexão; ela pode ter sido removida, ou esta lista está desatualizada") e duas saídas — "Tentar de novo", que invalida `pacing-knobs` (quando o item aparece, o efeito de hidratação preenche o formulário e o painel normal assume), e "Fechar". A segunda perna (`!form`) segue muda de propósito: é o frame transitório entre o item chegar e a hidratação rodar. Testes em tests/unit/protecao-de-envio-abre-e-avisa.test.tsx: comportamento nas duas provas — spy no queryClient exigindo as duas chaves; item nulo exigindo mensagem + "Tentar de novo" — com controle do fluxo normal e um caso ponta a ponta pelo cartão da conexão.
|
@webtecnica is attempting to deploy a commit to the rafael-maudibrasil's projects Team on Vercel. A member of the Team first needs to authorize it. |
ECC Tools / Security EvidenceCommit: Security evidence gate passed (success) No security-sensitive scanner-evidence gap detected. Mode: enforce Scanned 4 changed file(s). No missing scanner-evidence signal was detected. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / PR Risk TaxonomyCommit: PR taxonomy review recommended (neutral) Detected 1 PR taxonomy bucket(s): CI/CD Recommendation. Scanned 4 changed file(s). Roadmap taxonomy buckets: CI/CD RecommendationCI, dependency, coverage, and contract signals should be routed into follow-up checks or verification work. Signals:
Paths:
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Reference Set ReadinessCommit: Reference set readiness gaps detected (neutral) Reference evidence present for 0/7 areas (0%) across 4 changed file(s). This check is based on files changed in this PR. Repository-level readiness is still reported by
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Hosted Promotion ReadinessCommit: Hosted promotion readiness passed (success) No hosted promotion evidence gaps detected across 4 changed file(s); 0 corpus scenarios had matching evidence. This check compares PR file changes against the evaluator/RAG promotion corpus in No evaluator corpus scenarios matched this PR. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
|
Recebido, @webtecnica — obrigado por isto. Duas coisas que vão parecer erro seu e não são:
Um mantenedor vai revisar de verdade — rodando os gates e reproduzindo o comportamento, não só Esta mensagem é automática e não diz nada sobre o seu PR: ela é sobre o processo. O que vem |
O melgarafael#669 acrescentou um t() em components/connections/AntiBanSheet.tsx sem a entrada correspondente em lib/i18n/dicionario.ts. O gate tests/unit/i18n-espanhol-cobre-a-tela.test.ts reprovava com 1 chamada caindo no português para quem escolheu es — e, como o CI de PR de fork fica bloqueado em action_required, quem pegou foi a medição local do test:unit (rc=1 após 400s). Medido: pnpm exec vitest run tests/unit/i18n-espanhol-cobre-a-tela.test.ts -> 5 passed.
ECC Tools / Security EvidenceCommit: Security evidence gate passed (success) No security-sensitive scanner-evidence gap detected. Mode: enforce Scanned 5 changed file(s). No missing scanner-evidence signal was detected. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / PR Risk TaxonomyCommit: PR taxonomy review recommended (neutral) Detected 1 PR taxonomy bucket(s): CI/CD Recommendation. Scanned 5 changed file(s). Roadmap taxonomy buckets: CI/CD RecommendationCI, dependency, coverage, and contract signals should be routed into follow-up checks or verification work. Signals:
Paths:
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Reference Set ReadinessCommit: Reference set readiness gaps detected (neutral) Reference evidence present for 0/7 areas (0%) across 5 changed file(s). This check is based on files changed in this PR. Repository-level readiness is still reported by
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Hosted Promotion ReadinessCommit: Hosted promotion readiness passed (success) No hosted promotion evidence gaps detected across 5 changed file(s); 0 corpus scenarios had matching evidence. This check compares PR file changes against the evaluator/RAG promotion corpus in No evaluator corpus scenarios matched this PR. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
|
O ajuste que a medição local pegou (e o CI não pegaria, por estar em Corrigido em O que medi (depois do ajuste):
O |
1 participant
O que este PR faz
Depois de criar, excluir ou reconectar um canal na mesma visita, o painel "Proteção de envio" volta a abrir; e quando a conexão some da lista, ele abre com um aviso honesto em vez de morrer mudo.
Antes: o funil único de invalidação (
invalidate) invalidava só["channel-sessions"], então o cache depacing-knobsficava velho e o painel abria sem os dados da conexão; e o<AntiBanSheet>era montado sempre, comif (!item || !form) return null— "painel fechado" e "conexão sumiu da lista" davam no mesmo silêncio: nada abria, nada explicava.Closes #669
Como resolve
components/connections/ConnectionsClient.tsx— o callbackinvalidate(por onde passam criar, excluir, reconectar e o health check) invalida["channel-sessions"]e["pacing-knobs"]; e o<AntiBanSheet>só é montado quandoantiBanIdestá setado, para "painel fechado" e "conexão sumiu da lista" deixarem de ser a mesma coisa.components/connections/AntiBanSheet.tsx— comitemnulo a MESMA folha abre com título, mensagem honesta ("não foi possível carregar a proteção desta conexão; ela pode ter sido removida, ou esta lista está desatualizada") e as saídas Tentar de novo (invalidapacing-knobs; quando o item aparece, ouseEffectexistente hidrata o formulário e o painel normal assume) e Fechar. O!formsegue mudo de propósito: é o frame transitório de hidratação.O que medi (comandos e saídas)
Testes focados —
pnpm exec vitest run tests/unit/protecao-de-envio-abre-e-avisa.test.tsx→ 6 passed (6), rc=0, 4,88s. Com os vizinhos (conexoes-excluir-canal,protecao-de-envio-aceita-data-em-branco,anti-ban-nao-congela-o-padrao,fuso-horario): 5 files passed, 47 passed (47), rc=0.Os testes são de comportamento (React Testing Library +
QueryClientProvider), não guarda de fonte: a prova 1 usa spy emqueryClient.invalidateQueriesexigindo as DUAS chaves; a prova 2 renderiza oAntiBanSheetcomitem=nulle exige a mensagem e o botão "Tentar de novo"; há controle do fluxo normal (item presente) e um caso ponta a ponta pelo cartão da conexão noConnectionsClient.Sabotagem (depois do commit; previsão escrita antes de rodar: 4 vermelhos de 6, e eram os previstos):
git checkout HEAD~1 -- components/connections/ConnectionsClient.tsx components/connections/AntiBanSheet.tsx→ Tests 4 failed | 2 passed (6). Restaurado comgit checkout HEAD -- <os dois>→ 6/6 verdes de novo egit statuslimpo.Gates —
eslintnos 3 arquivos tocados rc=0, com 1 warning pré-existente (react-hooks/set-state-in-effectnouseEffectantigo doAntiBanSheet, confirmado idêntico no HEAD) — nenhum warning novo, nada silenciado e nada refatorado fora do escopo; e a fila local completa (um pesado por vez —flock+systemd-run --scope -p MemoryMax=5G):pnpm typecheckpnpm lintpnpm lint:channelspnpm lint:role-rankpnpm release:conferirpnpm test:unitpnpm test:shellpnpm buildNota honesta da primeira passada: a rodada inicial do
test:unitpegou a catraca de i18n — a frase nova do painel estava sem a entrada emlib/i18n/dicionario.ts(1 failed | 8.368 passed). A tradução entrou no mesmo branch (commitd0def504) e a re-rodada fechou limpa.O que NÃO medi
tests/invariants/**— precisa de Postgres/Docker, fora do include do vitest focado.