Confirm production/staging overlays enable retransmitPersistenceDir

[pedrosakuma]

Context

Follow-up from research done for pedrosakuma/B3TradingPlatform#793 (RFC on roll-triggered Ambiguous/Stale reclassification). Default production deployment ships with retransmitPersistenceDir: "" (deploy/charts/b3-matching/values.yaml:132), meaning any process restart is ephemeral: FIXP session state and outbound journal are lost, forcing a Renegotiated (rolled) reconnect even though the matching engine's own order-book WAL may survive underneath.

What to investigate

• Confirm, across actual production/staging Helm overlays (not just the chart default), whether retransmitPersistenceDir is set anywhere it matters. This determines whether restarts in practice hit the ephemeral path (forcing a roll + trading-side Ambiguous/Stale) or the persisted path (Reattached, no roll).
• If it is not set in any environment that matters, evaluate whether it should be — the persistence path is already implemented (FileFixpSessionStatePersister, wired conditionally in ExchangeHost.cs:658-683), so enabling it may be a low-risk way to reduce roll frequency without any protocol or trading-side change.
• Document the finding (and, if changed, the new default) in ops runbooks.

Why this matters

This is one of two config-only levers (the other being graceful-shutdown handling, tracked separately) identified as capable of reducing how often B3TradingPlatform's ConnectSessionRollReactor fires its blanket Ambiguous/Stale reclassification — without touching that reactor's semantics.

Non-goals

Not proposing a change to the persistence mechanism itself, only confirming/adjusting whether it's enabled where it should be.

cc @pedrosakuma
Refs pedrosakuma/B3TradingPlatform#793

[pedrosakuma]

Orquestração\n\nPrioridade: P1 — executar em paralelo com #613. É a verificação de configuração com maior potencial de reduzir rolls sem mudança de protocolo.\n\nEntregáveis/aceite:\n- Inventariar overlays de produção e staging, além do valor default do chart, para tcp.retransmitPersistenceDir e quotas do journal.\n- Publicar uma matriz ambiente → valor efetivo → impacto (Reattached/Renegotiated).\n- Se estiver ausente onde necessário, abrir/implementar a alteração mínima de values/secret/config e documentar rollback; se não houver evidência suficiente, deixar o bloqueio explícito.\n\nDependências: nenhuma de código; usar #613 para alinhar a interpretação do shutdown. Informar #615 sobre o caminho de persistência realmente usado.

[pedrosakuma]

Execução iniciada\n\nA resolução foi delegada à frente de overlays/persistência. O resultado esperado é uma matriz ambiente/configuração e alteração local segura quando comprovada.

[pedrosakuma]

Resultado consolidado\n\nProdução está configurada com retransmitPersistenceDir=/var/lib/b3matching/fixp-sessions; quotas efetivas herdadas permanecem 256 MiB/24h, permitindo Reattached se o PVC sobreviver. O chart default e configs locais deixam o campo vazio, mantendo Renegotiated em instalações sem overlay. Não foi encontrado overlay de staging neste repositório nem em B3Deploy; a confirmação de staging permanece bloqueada por evidência externa. Documentação do simulador e runbook atualizada.\n\nStatus: parcialmente resolvida; manter aberta até confirmar staging.

[pedrosakuma]

Follow-up aberto no repositório de deploy\n\nNão há overlay de staging no B3MatchingPlatform nem no B3Deploy; a busca encontrou apenas envs/prod/values.yaml, com tcp.retransmitPersistenceDir: /var/lib/b3matching/fixp-sessions.\n\nAberto pedrosakuma/B3Deploy#62 para confirmar a existência/configuração de staging, quotas efetivas e outcome esperado (Reattached vs Renegotiated). A issue permanece aberta até esse aceite.