[Quickfixj-users] Behaviour of SessionSchedule reset when a session is disabled (PR #1181)

[Raghuvansh <ra9...@gm...>]

I wanted to share a fix I recently submitted and get feedback from anyone
who may have encountered this edge case.

The issue:-

When a session is disabled (for example, after calling logout()) and has no
active connection, Session.next() returns early before reaching the
SessionSchedule check. This means the scheduled reset never runs, even when
it should.

If messages were queued via sendToTarget() during this time, they advance
the sequence numbers in the message store. Since no reset occurs at the
scheduled boundary, the sequence numbers remain out of sync. When the
session eventually reconnects, the counterparty expects sequence number 1
but receives a higher number, leading to a sequence number mismatch and
potential message loss.

The fix:-

The change removes the early return for the disabled + not-logged-on case,
allowing execution to fall through to the session schedule block before
returning.

The existing state.isResetNeeded() check already ensures that a reset only
occurs when sequence numbers have advanced beyond 1, so no additional logic
was required.

Question for the list:-

I am curious whether anyone has encountered scenarios where this interacts
with logon/logout timing in multi-session configurations. Specifically,
does letting a disabled session fall through to the schedule check cause
any unintended behaviour in setups where sessions are frequently enabled
and disabled across day boundaries?

The full context is in issue #965 and PR #1181 on GitHub.

Thanks in advance for any thoughts.