Dead Restarts

O que acontece com nossa solução se a conexão for instável ou cair inesperadamente.

O sistema mantém a normalidade em reconnect?

A resposta curta e direta é: *Sim! A normalidade é mantida e a recuperação é 100% transparente.* Se a conexão cair, o DBA só precisa clicar em "Reconnect" ou tentar rodar a query de novo no DBeaver, e a mágica acontece.

Deixe-me explicar como a nossa arquitetura lida com a "Morte e Ressurreição" das conexões, graças ao isolamento de processos do Gleam/Erlang.

O Ciclo de Morte da Conexão

Como o nosso túnel não guarda "estado" (ele é apenas um cano de passagem), a queda da conexão dispara um efeito dominó de limpeza (Cleanup) muito elegante:

*Cenário 1: A Internet do Cliente (Agente) Caiu ou o Postgres Reiniciou*

1. A malha P2P detecta a queda e o Yamux envia um sinal de encerramento (yamux.Close) para o Gateway.
2. O nosso loop imortal recebe esse yamux.Close e avisa o Ator piper no Gateway.
3. O piper do Gateway executa um tcp.close(state.tcp_socket) e o Ator se autodestrói (actor.stop()).
4. O DBeaver do DBA recebe um aviso do sistema operacional: "Connection closed by peer".

*Cenário 2: O DBA fechou o DBeaver ou a internet dele caiu*

1. O Ator piper no Gateway detecta que o socket TCP físico foi fechado e recebe a mensagem TcpClosed.
2. Ele envia um frame de yamux.Close pelo túnel P2P para o Agente e se autodestrói.
3. O Agente recebe o fechamento remoto, avisa o piper dele, que por sua vez fecha a conexão local com o PostgreSQL do cliente e morre em paz.

Em ambos os casos, *nenhum processo zumbi fica sobrando na memória RAM*. O túnel é completamente desfeito e varrido do mapa em milissegundos.

A Ressurreição (Como volta ao normal?)

Quando o DBA clica em "Reconnect" no DBeaver:

1. O tunnel_accept_loop aceita o novo socket.
2. Ele olha no dicionário (Agent Registry), acha o Agente ativo e pede para abrir um *novo* Stream Yamux (/horus/tunnel/1.0.0).
3. O Agente aceita e abre uma *nova* conexão local com o PostgreSQL.
4. O DBeaver envia o Handshake de 8 bytes novamente, o banco pede a senha, e a ponte está de pé como se nada tivesse acontecido!

E qual o papel das 24 horas (86_400_000 ms)?

Aquele timeout serve apenas como uma *Válvula de Segurança Extrema (Dead Man's Switch)*. Em redes de computadores mal configuradas, às vezes um roteador trava e a conexão cai de forma tão feia que o pacote de aviso (FIN ou RST do TCP) nunca chega. Se isso acontecer, o DBeaver vai ficar "congelado" e o nosso Ator Gleam ficaria pendurado na memória para sempre esperando uma mensagem que nunca virá.

O timeout de 24 horas diz à Máquina Virtual: "Olha, se este DBA não mandar nem um único byte por um dia inteiro, assuma que ele foi embora, feche o banco de dados e libere a RAM".