fix(drift): indisponibilidade não é drift, e o retry não segurava - #10
Merged
Conversation
Corrige um diagnostico meu que o run seguinte desmentiu. No #8 eu afirmei que o www.cgibs.gov.br bloqueava o runner do GitHub, com base num unico run em que ele deu timeout e os tres alvos de tributos.gov.br responderam. O run seguinte inverteu: CGIBS MATCH e os outros tres em timeout. Nao e bloqueio de host; e a rota dos runners para gov.br sendo intermitente. Mesma conclusao apressada, a partir de uma observacao so, que este projeto ja pagou caro uma vez. Tres mudancas: 1. Retry que cobre a janela real. Eram 3 tentativas com 2s fixos, ou seja 6s, e dois runs seguidos furaram. Agora 5 tentativas com espacamento exponencial (2, 4, 8, 16s), ~30s de janela. 2. Titulo de issue por natureza do problema. Chamar indisponibilidade de "Drift detectado nos contratos oficiais" ja abriu duas issues em falso (#4 e #9). Agora indisponibilidade tem titulo proprio e um corpo que diz, antes de qualquer coisa, que aquilo pode ser rede e como confirmar em 30 segundos. 3. O registro da rotina corrigido: a issue #6 nasceu em 17/08, nao 31/08, e ficou 18 dias sem tratamento, nao 4. Eu tinha lido a coluna de atualizacao do gh issue list como se fosse a de criacao. O 3 e o mais importante dos tres. A deteccao automatica funcionou e avisou tres vezes; o que falhou foi a resposta. E um detector que abre issue em falso por soluco de rede ensina o mantenedor a ignorar o alarme, o que explica 18 dias de silencio melhor do que desatencao. 5 testes novos, 41 no total.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Corrige um diagnóstico meu que o run seguinte desmentiu, e o ruído que vem confundindo o alarme desde agosto.
O que eu afirmei errado
No #8 eu escrevi, no código e no README, que
www.cgibs.gov.brbloqueava o runner do GitHub. Base: um run em que ele deu timeout e os três alvos detributos.gov.brresponderam.O run seguinte inverteu:
Não é bloqueio de host nenhum. É a rota dos runners do GitHub para
gov.brsendo intermitente. Conclusão apressada a partir de uma observação só, que é exatamente o erro que custou os 11 dias do v1.1.0, repetido por mim três horas depois de documentá-lo.O que muda
1. Retry que cobre a janela real. Eram 3 tentativas com 2s fixos, 6s de janela, e dois runs seguidos furaram. Agora 5 tentativas com espaçamento exponencial (2, 4, 8, 16s), cerca de 30s.
2. Título de issue por natureza do problema. Chamar indisponibilidade de "Drift detectado nos contratos oficiais" já abriu duas issues em falso: a #4 (03/08, fechada como "soluço de rede no runner") e a #9 (hoje). Agora indisponibilidade tem título próprio, e o corpo abre dizendo que aquilo pode ser rede, com o comando para confirmar em 30 segundos.
3. O registro corrigido. A issue #6 nasceu em 17/08, não 31/08, e ficou 18 dias sem tratamento, não 4. Eu li a coluna de atualização do
gh issue listcomo se fosse a de criação.Por que o item 3 é o mais importante
A detecção automática funcionou. Pegou o drift em 17/08 e avisou de novo em 24/08 e 31/08. Três avisos, dezoito dias, nenhuma resposta.
Isso muda o diagnóstico da auditoria de hoje. Eu tinha registrado "falha de detecção" para o v1.1.0 e "falha de resposta" para o drift da Calculadora, como se fossem coisas separadas. Olhando junto: um detector que abre issue em falso por soluço de rede ensina o mantenedor a ignorar o alarme. Duas issues em falso e três avisos verdadeiros ignorados, no mesmo período, não são coincidência. O ruído é o que corrói a resposta.
Por isso o título da issue não é detalhe cosmético, é a correção do sinal.
Verificação
node scripts/drift-check.mjslocal: 4/4 MATCH.