hotfix(deploy): remove endpoint Https sem certificado + corrige rollback mudo - #333
Merged
elson-vinicius-lopes merged 2 commits intoSep 8, 2026
Conversation
…ack mudo Incidente de producao (2026-09-07, apos ativar MIGRATE_CONFIG_TO_REPO na issue #112): o deploy que migrou appsettings.json inteiro pro servidor introduziu Kestrel:Endpoints:Https:Url pela primeira vez em producao (nunca tinha chegado la antes - appsettings.json era preservado, nao versionado). Sem certificado configurado, o Kestrel falhava ao subir em loop de crash: "Unable to configure HTTPS endpoint. No server certificate was specified". O Windows Service ficava "Running" (processo vivo, reiniciando sozinho) mas a porta 5000 nunca respondia - servico efetivamente fora do ar. Fix 1: remove a secao Https do appsettings.json versionado. A API roda loopback-only atras do BFF (ver security.md) - nao usa terminacao HTTPS nesta camada. Mitigado manualmente em producao via edicao direta do appsettings.json + restart do servico (confirmado: readiness 200 de volta). Fix 2 (achado durante a investigacao): o rollback automatico do smoke test (PR #114, incidente de 2026-08-15) nunca teria executado neste caso, e possivelmente nunca executou em nenhum deploy falho anterior. Toda chamada Write-Error dentro do bloco de rollback (linhas ~1319-1396) e SEMPRE terminante com $ErrorActionPreference="Stop" (topo do step) - o script abortava no primeiro Write-Error, antes de sequer tentar restaurar o backup. Trocadas por Write-Host (nao-terminante), deixando o fluxo chegar no rollback de verdade e no resumo/e-mail de alerta que ja existiam. Sem os dois fixes, o proximo deploy que reintroduzisse qualquer chave "so no repo" arriscada (nao so Https) ficaria preso do mesmo jeito, sem rollback nenhum tirando producao do estado quebrado. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
elson-vinicius-lopes
deleted the
hotfix/kestrel-https-crash-loop-e-rollback-mudo
branch
September 8, 2026 00:10
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.
Incidente de produção (2026-09-07)
Após ativar
MIGRATE_CONFIG_TO_REPO=true(issue #112) e disparar um deploy, produçãoficou fora do ar: o Windows Service mostrava "Running", mas a porta 5000 não respondia
nada (
Unable to connect to the remote server).Causa raiz: a migração copiou o
appsettings.jsoninteiro do repo pro servidor pelaprimeira vez — trazendo junto
Kestrel:Endpoints:Https:Url, uma chave que nunca tinhachegado lá antes (o arquivo era preservado, não versionado, até agora). Sem certificado
configurado em produção, o Kestrel falhava ao subir em loop de crash:
Mitigado manualmente em produção (edição direta do
appsettings.jsonremovendo a seçãoHttps+ restart do serviço — confirmado: readiness voltou a 200).Achado colateral durante a investigação: rollback automático nunca funcionaria
O smoke test pós-deploy (PR #114, incidente de 2026-08-15) existe exatamente pra reverter
automaticamente uma versão que falha o readiness check. Ele nunca chegou a tentar isso
neste incidente — e possivelmente nunca funcionou em nenhuma falha anterior.
Motivo: todo
Write-Errordentro do bloco de rollback (linhas ~1319-1396) é sempreterminante, porque
$ErrorActionPreference = "Stop"está setado no topo do step. Oscript abortava no primeiro
Write-Error— antes mesmo de entrar notryque restaura obackup.
Fix
appsettings.json: remove a seçãoKestrel:Endpoints:Https— a API rodaloopback-only atrás do BFF (ver
security.md), não usa terminação HTTPS nesta camada.deploy.yml: troca os 4Write-Errordo bloco de rollback porWrite-Host(não-terminante), deixando o fluxo chegar de fato no rollback, no resumo do
GITHUB_STEP_SUMMARYe no alerta por e-mail que já existiam.Build validado localmente (
dotnet build, 0 erros, JSON válido).Mexe em config de produção e no mecanismo de rollback do deploy. Recomendo mergear e
confirmar com um deploy real (ou pelo menos revisar o próximo smoke-test-fail simulável)
antes de considerar o mecanismo de rollback validado de fato.
🤖 Generated with Claude Code