AdminRequest::ResetSequenceNumbersOnNextLogon sets self.reset_on_next_logon — a bool on the Session struct — which is only consumed inside send_logon(). If the process restarts between the admin command and the next logon attempt, the flag is lost and the reset silently does not happen.
There is also a latent bug in the existing clearing logic: the flag is cleared eagerly immediately after store.reset() in send_logon(), before the Logon has been sent or acknowledged. If the Logon write fails or the connection drops before the peer sees it, our store is reset but the intent is gone, and the next reconnect sends Logon(141=N, seq=1) into a peer that still has its old counters — straight into a fatal disconnect.
Proposal
Move the flag into the MessageStore so it's durable. Change the clearing point: clear on successful transition to Active rather than eagerly after store.reset(), so a failed logon leaves the flag set for the next attempt to retry. store.reset() is idempotent, so repeated invocation across retries is safe.
Acceptance
MessageStore gains a persisted "pending reset" flag with the usual set / query / clear surface.
send_logon() reads the store flag in place of the in-memory bool; self.reset_on_next_logon is removed from Session.
- The flag is cleared on successful transition to
Active, not eagerly after store.reset(). This closes the pre-existing bug where a failed Logon after store reset would leave the session unable to retry the reset on reconnection.
AdminRequest::ResetSequenceNumbersOnNextLogonsetsself.reset_on_next_logon— aboolon theSessionstruct — which is only consumed insidesend_logon(). If the process restarts between the admin command and the next logon attempt, the flag is lost and the reset silently does not happen.There is also a latent bug in the existing clearing logic: the flag is cleared eagerly immediately after
store.reset()insend_logon(), before the Logon has been sent or acknowledged. If the Logon write fails or the connection drops before the peer sees it, our store is reset but the intent is gone, and the next reconnect sendsLogon(141=N, seq=1)into a peer that still has its old counters — straight into a fatal disconnect.Proposal
Move the flag into the
MessageStoreso it's durable. Change the clearing point: clear on successful transition toActiverather than eagerly afterstore.reset(), so a failed logon leaves the flag set for the next attempt to retry.store.reset()is idempotent, so repeated invocation across retries is safe.Acceptance
MessageStoregains a persisted "pending reset" flag with the usual set / query / clear surface.send_logon()reads the store flag in place of the in-memory bool;self.reset_on_next_logonis removed fromSession.Active, not eagerly afterstore.reset(). This closes the pre-existing bug where a failed Logon after store reset would leave the session unable to retry the reset on reconnection.