Você abre o Hermes para recuperar a sessão de ontem e leva um seco session not found — mas você lembra claramente que ela existe. Pior: o state.db (o banco SQLite onde o Hermes guarda todo o histórico de sessões) é corrompido por completo e meses de conversas “desaparecem”. No passado, essa classe de problema era quase impossível de diagnosticar: a mensagem de erro escondia a causa real (corrupção do banco), e o sistema continuava escrevendo no banco quebrado, fazendo o estrago virar uma bola de neve. Um lote de correções mesclado em 30-31 de agosto (PR #99513 e seus PRs irmãos) dá ao Hermes, pela primeira vez, uma forma sistemática de lidar com corrupção de banco: detectá-la, quarentenizar o arquivo ruim, curar o que pode ser curado e dizer claramente quando não dá.

Por que era tão difícil diagnosticar antes

O state.db é um arquivo SQLite — robusto na teoria, mas ainda assim corrompível após queda de energia, disco cheio, processo travado ou aberturas concorrentes de múltiplos processos. No passado, a atitude do Hermes diante da corrupção era “fingir que nada aconteceu”:

• Ao ler dados ruins, a UI só mostrava session not found, engolindo o fato de que “o banco de dados está corrompido”;
• Um banco estruturalmente quebrado continuava aceitando escritas — dados novos despejados num armazém quebrado, como encher um balde furado;
• Um arquivo vazio de 0 bytes era confundido com um “banco recém-criado” e aberto normalmente — até a primeira escrita real falhar com attempt to write a readonly database;
• Com vários processos abrindo o mesmo banco, um processo podia classificar como corrompido o banco vazio que outro processo acabara de criar legitimamente e quarentenizá-lo.

O que este lote corrige

Seis PRs, abrangendo quatro fases: detecção, quarentena, cura e proteção.

Detectar corrupção em vez de fingir

• Reportar “corrupção” em vez de “session not found” (PR #99529): a detecção de corrupção entra no caminho de leitura, então o problema aparece com uma mensagem clara em vez de um erro enganoso;
• Bancos estruturalmente corrompidos param de aceitar escritas (PR #99652): fail-closed — recusar escritas em vez de despejar dados num armazém quebrado;
• Conexões de leitura são limitadas por arquivo, não por instância de SessionDB (PR #98691): antes cada instância tinha seu próprio orçamento de conexões, então a contagem de conexões disparava com várias instâncias — um gatilho para esgotamento de file descriptors e travamentos.

Quarentenizar arquivos de 0 bytes

• Um state.db truncado de 0 bytes é quarentenizado (PR #98017): o arquivo vazio é movido para o lado na inicialização em vez de ser aberto como um banco normal;
• Lock entre processos corrige a corrida da quarentena (PR #99513, sub-cluster A): toda a sequência check → quarantine → connect → schema-commit roda agora sob um lock entre processos, com uma proteção has_live_connection() resguardando bancos “vazios, mas legitimamente em uso” — um processo não consegue mais quarentenizar o banco recém-criado de um irmão.

Autocura do índice FTS de texto completo

• UnicodeDecodeError não quebra mais a sondagem do índice (PR #99513, sub-cluster B): tabelas corrompidas de busca full-text (FTS) podem lançar erros de decodificação, que antes matavam a inicialização somente leitura e todos os endpoints de leitura atrás dela; as sondagens e os caminhos de cura agora capturam esses erros, e tabelas FTS quebradas são descartadas e recriadas.

Eliminar corridas da classe de crash

• Leituras não sincronizadas na conexão de escrita compartilhada acabaram (PR #99502): essa classe podia causar crashes no nível de SIGSEGV em casos extremos;
• Corridas entre close() e escritas em segundo plano se autocuram (PR #99509): quando a conexão de escrita fecha com escritas ainda em voo, o sistema se repara em vez de descartar dados em silêncio.

O que isso significa para você

Se o seu histórico de sessões já “desapareceu misteriosamente”, este lote muda todo o pipeline de tratamento: detecção na frente → quarentena do arquivo ruim → cura do que é curável (tabelas FTS) → e quando não dá para curar, um erro claro — sem nunca continuar escrevendo no armazém quebrado. A confiabilidade dos dados de sessão passa de “pode desaparecer um dia” para “no mínimo o problema está explicado e o estrago para de crescer”.

Quando você pode usar

Esses PRs foram mesclados em 30-31 de agosto de 2026 e estão todos apenas na main — ainda não saíram em uma release. Atualize para a main mais recente para obter a proteção completa; se você já levou um session not found ou perdeu sessões antes, vale reler as mensagens de erro depois de atualizar — elas agora dizem o estado do banco diretamente.

Seu histórico de sessões é a memória de trabalho entre você e o Hermes — sua confiabilidade merece cuidado. Para outras formas de proteger dados de sessão, veja o guia de salvar e exportar sessão e o postmortem da amnésia de 798 mensagens; como a compressão interage com o histórico está coberto no guia de compactação em uma chamada.