Skip to content

fix(atualizacao): a tela conta em que pé está, nas duas pontas do silêncio - #717

Open
paulolimajr77 wants to merge 2 commits into
melgarafael:mainfrom
paulolimajr77:fix/tela-de-atualizacao-conta-o-pe
Open

fix(atualizacao): a tela conta em que pé está, nas duas pontas do silêncio#717
paulolimajr77 wants to merge 2 commits into
melgarafael:mainfrom
paulolimajr77:fix/tela-de-atualizacao-conta-o-pe

Conversation

@paulolimajr77

Copy link
Copy Markdown
Contributor

As duas pontas têm a mesma causa: o app e o host conversam por batidas de 5 em 5 minutos, e a tela afirma estado como se a conversa fosse instantânea.

Ponta 1 — o clique não começa a atualização

POST /api/v1/system/update só registra o pedido; quem executa é o agent.sh, no ciclo seguinte. Até lá last_step é nulo — e a tela já mostrava o título "Atualizando para a versão X" com os quatro círculos vazios. Ela afirma trabalho que ainda nem começou, e fica imóvel por até cinco minutos. Quem clicou não tem como distinguir isso de travamento.

Agora a espera é estado próprio, com nome ("Pedido enviado — esperando o servidor pegar"), com a razão da demora, com o aviso de que ficar parada é normal, e com um relógio que anda — contado do dispatched_at do servidor, para recarregar a página não zerar a conta. A lista de passos só aparece quando existe um passo.

Ponta 2 — e esta era pior

run_result com success fecha o run e não escreve current_version; quem escreve é o heartbeat. Nessa janela update_available (latest !== current) segue verdadeiro e a tela volta do reinício oferecendo "Atualizar agora" para a versão que acabou de ser instalada. Quem clicou refaz tudo, ou conclui que não funcionou.

O conserto é sucessoJaInstalado, irmão de rollbackFoiSuperado e no mesmo módulo: o mesmo desempate temporal, na direção contrária. Lá o host mais novo vence o run; aqui o run vence enquanto o host não falou. Tem fim de validade por construção — na batida seguinte devolve false sozinho, sem ninguém limpar estado nenhum.

Empate de segundo conta como "host calado": as duas escritas vêm de relógios diferentes, e errar para esse lado custa um rótulo otimista por minutos, enquanto errar para o outro devolve o botão que manda instalar de novo o que já está lá.

O que medi

⚠️ O caso e2e do caminho feliz AFIRMAVA o defeito da ponta 1 — esperava "Guardando uma cópia de segurança" logo após o clique, ou seja, cobrava que a tela mentisse. Reescrito: percorre as duas pontas, e a janela do defeito ficou explícita — entre o run_result e a recarga não há heartbeat nenhum.

  • lib/system/update-run.test.ts — 7 casos novos no sucessoJaInstalado, incluindo o fim de validade e o empate
  • app/api/v1/system/version/route.test.ts — 3 casos: a janela, o fechamento pela batida do host, e o dispatched_at que a tela usa de relógio
  • as dez frases novas entram no dicionário (o gate de espanhol as pegou; sem elas, quem opera em espanhol via a tela em português justo nos estados que explicam a demora)

Sabotagem conferida: acabouDeInstalar forçado a false derruba 1 de 28 no teste da rota — o previsto.

Gates na prévia do merge: typecheck 0, testes da área 58/58.

Provado em tela, numa VPS real, atualizando de verdade: o "Pedido enviado" com o contador subindo, e o "Pronto — você está na versão X" sem botão ao terminar.

O que NÃO medi

  • pnpm test:unit inteiro nesta branch (rodei na branch de origem: 5 vermelhos, os 4 conhecidos de Windows + o do espanhol, que este PR já traz corrigido)
  • a corrida do pnpm test:e2e — a spec alterada roda no CI, em SPECS_PARTE_1

🤖 Generated with Claude Code

paulolimajr77 and others added 2 commits September 11, 2026 18:50
…encio

As duas pontas tinham a mesma causa: o app e o host falam por batidas de 5
em 5 minutos, e a tela afirmava estado como se a conversa fosse instantanea.

PONTA 1 — o clique nao comeca a atualizacao. `POST /update` so registra o
pedido; quem executa e o `agent.sh`, no proximo ciclo. Ate la `last_step` e
nulo, e a tela ja mostrava o titulo "Atualizando para a versao X" com os
quatro circulos vazios: afirmava trabalho que ainda nem tinha comecado, e
ficava imovel por ate cinco minutos. Agora a espera e um estado proprio, com
nome, com a razao da demora, com o aviso de que ficar parada e normal, e com
um relogio que anda — contado do `dispatched_at` do servidor, para recarregar
a pagina nao zerar a conta.

PONTA 2 — e esta era pior. `run_result` com sucesso fecha o run e NAO escreve
`current_version`; quem escreve e o heartbeat. Nessa janela
`update_available` (`latest !== current`) seguia verdadeiro e a tela voltava
do reinicio oferecendo "Atualizar agora" para a versao que ACABOU de ser
instalada. Quem clicava refazia tudo, ou concluia que nao funcionou.

O conserto da ponta 2 e `sucessoJaInstalado`, irmao de `rollbackFoiSuperado`
e no mesmo modulo: o mesmo desempate temporal, na direcao contraria. La o
host mais novo vence o run; aqui o run vence enquanto o host nao falou. Tem
fim de validade por construcao — na batida seguinte devolve `false` sozinho,
sem ninguem limpar estado nenhum. Empate de segundo conta como "host calado":
errar para esse lado custa um rotulo otimista por minutos, e errar para o
outro devolve o botao que manda instalar de novo o que ja esta la.

⚠️ O caso e2e do caminho feliz AFIRMAVA o defeito da ponta 1 — esperava
"Guardando uma copia de seguranca" logo apos o clique. Foi reescrito e agora
percorre as duas pontas, com a janela do defeito explicita: entre o
`run_result` e a recarga NAO ha heartbeat nenhum.

Sabotagem conferida: `acabouDeInstalar` forcado a `false` derruba 1 de 28 no
teste da rota — o previsto.

NAO MEDI: a suite inteira (fica para o fim da fila) e a corrida do e2e, que
precisa de Supabase local e app buildado — roda no CI, em SPECS_PARTE_1.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A suite inteira apontou: `i18n-espanhol-cobre-a-tela` reprovou os dez `t()`
que entraram no `UpdatePanel` com o conserto das duas pontas do silencio
(cb55c83). Sem entrada no dicionario, `traduzir` degrada para o proprio
texto — quem opera em espanhol via a tela em portugues, e justo nos estados
novos, que sao os que explicam por que a tela parece parada.

Foi o UNICO vermelho meu na suite: 5 arquivos falharam, 4 batem com a tabela
de vermelhos de Windows da NOSSA-REGRA.md (`lgpd-pdf-meet`,
`lgpd-pdf-replies`, `suporte-cobertura-de-efeitos`,
`rascunho-superado-nao-e-regravado`).

⚠️ Os rotulos de fuso NAO sao alcancados por essa cerca: as telas chamam
`t(f.rotulo)`, com variavel, e a varredura so enxerga literal. Nao e regressao
deste trabalho — o onboarding ja fazia `t(f.cidade)` antes —, mas e um buraco
conhecido da cerca, nao uma ausencia de problema.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@vercel

vercel Bot commented Sep 11, 2026

Copy link
Copy Markdown

@paulolimajr77 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

ecc-tools Bot commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

ECC Tools / Security Evidence

Commit: b74c9a8ac96c0d2f48b0a3c426e538757d217316

Security scanner evidence required (action_required)

Detected 1 security-sensitive predictive risk signal(s) without scanner evidence.

Mode: enforce

Findings:

  • Security-sensitive changes may ship without scanner evidence: The PR touches billing, secrets, auth, webhooks, agent, or CI-sensitive surfaces without adding obvious security scanner, code scanning, or security-focused validation evidence. (1 security-sensitive paths changed; 0 security scanner or security-focused validation artifacts changed)

Touched security-sensitive paths:

  • hooks/system/useSystemVersion.ts

Expected evidence:

  • Security scanner, code scanning, secret scanning, dependency/security review, or focused security regression output.
  • SARIF/code-scanning upload or equivalent pass/fail gate for the changed surface.

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

ecc-tools Bot commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

ECC Tools / PR Risk Taxonomy

Commit: b74c9a8ac96c0d2f48b0a3c426e538757d217316

PR taxonomy review recommended (neutral)

Detected 2 PR taxonomy bucket(s): Security Evidence, CI/CD Recommendation.

Scanned 9 changed file(s).

Roadmap taxonomy buckets:

Security Evidence

Security-sensitive changes should carry explicit scanner, code-scanning, or focused regression evidence.

Signals:

  • Security-sensitive changes may ship without scanner evidence
  • 0 security-sensitive path(s) changed

Paths:

  • .changes/a-tela-de-atualizacao-conta-em-que-pe-esta.md
  • app/api/v1/system/version/route.test.ts
  • app/api/v1/system/version/route.ts

CI/CD Recommendation

CI, dependency, coverage, and contract signals should be routed into follow-up checks or verification work.

Signals:

  • API implementation changes may ship without contract artifact updates
  • 3 CI or workflow path(s) changed

Paths:

  • app/api/v1/system/version/route.test.ts
  • lib/system/update-run.test.ts
  • tests/e2e/system-update.spec.ts
  • app/api/v1/system/version/route.ts
  • app/app/settings/atualizacao/_components/UpdatePanel.tsx
  • hooks/system/useSystemVersion.ts
  • lib/i18n/dicionario.ts
  • lib/system/update-run.ts

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

ecc-tools Bot commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

ECC Tools / Reference Set Readiness

Commit: b74c9a8ac96c0d2f48b0a3c426e538757d217316

Reference set readiness gaps detected (neutral)

Reference evidence present for 0/7 areas (0%) across 9 changed file(s).

This check is based on files changed in this PR. Repository-level readiness is still reported by /ecc-tools analyze comments and generated manifests.

Area Status Evidence / Next Step
Deep analyzer corpus Missing Add analyzer fixture, golden, benchmark, or reference-set files that can catch analyzer regressions.
RAG/evaluator comparison Missing Add retrieval or evaluator reference-set comparison fixtures with expected ranking behavior.
PR salvage/review corpus Missing Add stale-PR, review-thread, reopen-flow, or salvage reference cases for queue cleanup automation.
Discussion triage corpus Missing Add public discussion triage fixtures, golden cases, or reference sets for informational, answered, and no-response classifications.
Harness compatibility Missing Add cross-harness, adapter-compliance, or harness-audit evidence for Claude, Codex, OpenCode, Zed, dmux, and agent surfaces.
Security evidence Missing Attach security evidence such as SBOMs, SARIF, audit reports, or AgentShield evidence packs.
CI failure-mode evidence Missing Add captured CI failure logs, dry-run fixtures, or troubleshooting docs for common workflow failure modes.

Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission.

@github-actions

Copy link
Copy Markdown

Recebido, @paulolimajr77 — obrigado por isto.

Duas coisas que vão parecer erro seu e não são:

  • O check Vercel vermelho ("Authorization required to deploy") é esperado em PR de fork. A
    main faz deploy de produção e a Vercel se recusa a construir código de fora, o que está
    certo. Ele não entra no gate de merge.
  • No primeiro PR de quem nunca contribuiu aqui, os workflows ficam parados esperando
    liberação
    — política do GitHub, não sua. Enquanto isso o PR parece não ter check nenhum
    (nem o gh pr checks mostra os que estão nesse estado). Quem tria libera; você não precisa
    fazer nada.

Um mantenedor vai revisar de verdade — rodando os gates e reproduzindo o comportamento, não só
lendo o diff — e responde aqui em até um dia útil, com a medição junto, nunca com um "acho
que".

Esta mensagem é automática e não diz nada sobre o seu PR: ela é sobre o processo. O que vem
depois é pessoa.

@ecc-tools

ecc-tools Bot commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

ECC Tools / Hosted Promotion Readiness

Commit: b74c9a8ac96c0d2f48b0a3c426e538757d217316

Hosted promotion readiness passed (success)

No hosted promotion evidence gaps detected across 9 changed file(s); 0 corpus scenarios had matching evidence.

This check compares PR file changes against the evaluator/RAG promotion corpus in src/analyzers/fixtures/evaluator-rag-corpus.ts.
Hosted output scoring inspected 0 completed cached hosted job results.

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.

@melgarafael

Copy link
Copy Markdown
Owner

Recebido — obrigado.

Duas coisas que vão parecer erro seu e não são:

  • O check Vercel vermelho ("Authorization required to deploy") é esperado em PR de fork. A main faz deploy de produção e a Vercel se recusa a construir código de fora, o que está certo. Ele não entra no gate de merge.
  • Os workflows ficam parados esperando liberação no primeiro PR de quem nunca contribuiu — política do GitHub, não sua. Acabei de liberar, o CI já está rodando.

Um aviso útil: a main andou doze PRs hoje e a v1.19.0 saiu. Se o seu ficar com conflito por causa disso, o conserto é do nosso lado — não precisa correr atrás. O mesmo vale para número de migration colidido e fragmento de release faltando.

Vou revisar de verdade — rodando os gates e reproduzindo o comportamento, não só lendo o diff — e volto com o resultado. Se eu achar algo, venho com a medição junto, nunca com um "acho que".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants