fix(u6c): a medição contradisse os três documentos - #247
Merged
Conversation
…aqui (R6)
O U6-c rodou com a v1.3.0 e o canal `stable` publicados. As quatro respostas:
1. O worker TROCOU numa execução só: local `7f53521f` → `deskcomm-worker:stable`,
`sha256:3fe292cad2bd…`, `revision=9bd59e93`, `version=1.3.0`. O digest bate com
o registrado no corte da release.
2. **Mas ficou SEM PIN.** `.env` com `APP_IMAGE=…:1.3.0` e `WORKER_IMAGE` ausente:
o app pinado numa versão e o worker seguindo um canal móvel. Na próxima release
o `stable` se move e um `up -d` — com `pull_policy: always`, o default de tag
móvel — levaria o worker sozinho para a versão nova enquanto o app fica na
antiga. É mistura de versões que acontece SOZINHA, e é o que o invariante 3
existe para impedir.
3. Detector: exit 0.
4. O rollback NÃO produz mais a imagem local disfarçada de registry — com `stable`
existindo o Compose puxa em vez de construir. O efeito colateral do U6-b some.
O que estava escrito e ficou errado, corrigido no mesmo commit:
- **runbook §5.0** dizia "a primeira execução NÃO conserta". Passou a mostrar as
DUAS medições lado a lado: sem `stable` publicado ela não traz o worker; com
`stable` ela traz mas não pina. A instrução ("rode duas vezes") sobrevive às
duas, mas o motivo é diferente, e a razão importa para quem lê.
- **CHANGELOG** dizia "pode não trocar o agente". Passou a dizer o que o operador
precisa saber: a primeira traz o agente e deixa a versão dele solta; a segunda
fixa. Sem jargão de tag ou canal.
- **doutrina**, item 11 do checklist: registra que apagar tag de pacote exige
`read:packages`/`delete:packages`, que o token padrão do `gh` não tem — medido
no corte da 1.3.0, onde o item ficou pendente por 403.
E o detector ganhou o aviso que faltava: worker publicado mas em tag MÓVEL sem pin
no `.env` não é o incidente (exit continua 0), mas é o estado que a primeira
execução produz e que a doutrina proíbe. Um aviso em cinza-claro era pouco.
Provado nos três casos — aviso=1 só em `:stable` sem pin; 0 em tag imutável e 0
depois da segunda execução.
Uma correção de método: a primeira tentativa do U6-c foi invalidada por defeito do
MEU ambiente, não do produto — o baseline exige os schemas `auth`/`storage`/
`extensions` e o update abortava neles. Passei a usar o mesmo prelude de stubs que
`scripts/test-db.sh` aplica no job `invariants`; com ele o baseline da época aplica
com ON_ERROR_STOP=1 e zero erros. Sem isso, o ensaio estaria medindo o ambiente.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RKm2XcTcfgi1vdMcDYSRWa
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
ECC bundle files are already tracked in this repository. Skipping generation of another bundle PR. |
…mpo mostrou Primeira aplicação em instalação real. A produção reproduziu o U6-c com exatidão, que é o que dá valor ao ensaio: worker de 31/07 (fb42e47c, local) → :stable na 1ª execução, sem pin, exatamente como previsto → 1.3.0 pinado na 2ª. /api/v1/health saiu de "0.1.0" para "1.3.0, healthy". De fora da VPS: HTTP 307, com supabase/redis/waha ok. Nada se perdeu, medido item a item: 48.607 arquivos no volume WAHA antes e depois, sessão noweb presente, 4 volumes, nenhuma chave do .env sumiu (39 → 43, as 4 novas são as de imagem). O backup precedeu tudo e foi verificado ANTES de qualquer escrita: 11 MB, gunzip -t íntegro, 69.523 linhas, 145 CREATE TABLE. O código chegou, e a prova é por hash, não por data: os arquivos que os 9 commits tocaram têm SHA-256 idêntico na tag v1.3.0 e dentro da imagem que a produção roda. "A imagem é de hoje" seria proxy; hash é o artefato. **O que só o campo mostrou:** o pin do WAHA não alcança instalação legada. O .env do parque tem `WAHA_IMAGE='devlikeapro/waha'` — sem tag, gravado pelo install antigo — e o .env vence o default do compose. O update.sh não reescreve essa chave, então a instalação segue puxando :latest a cada dc pull, recebendo qualquer versão que o upstream publique sem ninguém testar. É o invariante 4 sendo violado por um resíduo que a remediação não limpa, e é o MESMO padrão do defeito que o install.sh já teve — o .env vencendo o compose —, agora do lado de quem já instalou. Deixado sem conserto de propósito: reescrever WAHA_IMAGE num .env alheio troca a versão do WhatsApp de uma instalação em produção. Isso merece decisão e ensaio próprios, não um remendo no fim de uma remediação que deu certo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RKm2XcTcfgi1vdMcDYSRWa
Contributor
|
ECC bundle files are already tracked in this repository. Skipping generation of another bundle PR. |
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.
O ensaio U6-c rodou com a v1.3.0 e o
stablepublicados, e o resultado contradisse o que estava escrito no runbook, no CHANGELOG e na doutrina. Os três mudam aqui (R6).O achado: com
stableexistindo, a primeira execução doupdate.shtroca o worker (digest bate com a release) mas o deixa sem pin —APP_IMAGE=…:1.3.0eWORKER_IMAGEausente. O app fica numa versão e o worker seguindo um canal móvel; na próxima release ostablese move e umup -dlevaria o worker sozinho. É o que o invariante 3 existe para impedir.A instrução ("rode duas vezes") sobrevive aos dois ensaios, mas por motivos diferentes — e a razão importa para quem lê.
O detector ganhou o aviso correspondente, provado em 3 casos (aviso só em tag móvel sem pin).
🤖 Generated with Claude Code
https://claude.ai/code/session_01RKm2XcTcfgi1vdMcDYSRWa