Handle every wallet status in the readiness gate - #23
Open
Ikari wants to merge 1 commit into
Open
Conversation
HathorWallet#isReady only recognized CONNECTING (1), SYNCING (2) and READY (3), but the headless wallet reports six states. The wallet reaches PROCESSING (5) after it finishes downloading history, while it processes what it just downloaded - a state a status check can legitimately land on, especially right after a restart. Landing there hit no branch, so the function fell off the end and resolved undefined. main.ts read that as "not ready" and then waited on a 'wallets-ready' event that only isReady itself can emit - and nothing re-checks afterwards. The federator would hang at boot, silently, with no error logged. Now: - PROCESSING joins CONNECTING and SYNCING as a transient state that retries. - CLOSED (0) and ERROR (4) take the restart path, alongside the existing "looks stopped" heuristic; start is idempotent, so it also recovers a wallet that died mid-sync. - Any unrecognized status warns and retries instead of falling through, so the function can never resolve undefined again. Adds test/HathorWallet.test.ts covering each state, including that exhausting the retry budget resolves to a definite false. Found while testing the upgrade to the official wallet image, but the gap is not new - PROCESSING already existed in wallet-lib 1.14, so this is latent on the current production image too. It was not reproducible on demand in testing: the PROCESSING window is short (a few seconds out of a ~40 s startup), which is why it has gone unnoticed rather than why it is harmless. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
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 caminho no gate de readiness que fazia o federator travar no boot, em silêncio.
Não mergear ainda — segue o mesmo ciclo do #22.
O bug
HathorWallet#isReadysó reconheciaCONNECTING (1),SYNCING (2)eREADY (3). A wallet headless reporta seis estados. Ela chega emPROCESSING (5)depois de baixar o histórico, enquanto processa o que baixou — um estado em que a checagem pode legitimamente cair, ainda mais logo após um restart.Caindo ali, nenhum
ifcasava, a função caía fora semreturne resolviaundefined. Omain.tslia isso como "não pronta" e passava a esperar o eventowallets-ready, que só o próprioisReadyemite — e nada mais re-checa depois. O federator travava no boot, sem log de erro.A correção
PROCESSINGentra junto comCONNECTINGeSYNCINGcomo estado transitório que faz retry.CLOSED (0)eERROR (4)vão para o caminho de restart, ao lado da heurística de "looks stopped" que já existia. Ostarté idempotente, então isso também recupera uma wallet que morreu no meio do sync.warne faz retry, em vez de cair fora — a função nunca mais pode resolverundefined.Testes
test/HathorWallet.test.ts, novo, 7 casos cobrindo cada estado — incluindo que esgotar o budget de retry resolve para umfalsedefinido.A suíte completa tem 5 falhas em
hathorEvent.test.js, pré-existentes: confirmei comgit stashque falham igual no master limpo, sem relação com esta mudança.Escopo e honestidade sobre o alcance
Encontrado enquanto eu testava a atualização da imagem da wallet, mas a lacuna não é nova —
PROCESSINGjá existia na wallet-lib 1.14, então é latente também na imagem que roda em produção hoje.Não consegui disparar sob demanda: subi o federator de propósito com a wallet em
PROCESSINGe ele repetiu a checagem e passou. A janela é curta — uns segundos num arranque de ~40 s. Isso explica por que passou despercebido, não por que seria inofensivo: restart é exatamente quando se cai nela.O budget de retry atual (5 tentativas, ~150 s no total) não foi alterado neste PR. Se em algum momento o sync voltar a demorar muito, ele estoura antes da wallet ficar pronta — vale revisitar separadamente, com um número escolhido a partir de medição.
🤖 Generated with Claude Code
https://claude.ai/code/session_013NgawoxTe2eyJZzUBBh7pr