Is it correct to apply *any* checking to sequence number tag 34 of a sequence reset - Reset message

@wof352020 thank you for raising the issue in this forum.

The specification for the FIX Session Layer has recently been refactored into a single specification (https://www.fixtrading.org/standards/fix-session-layer-online/) with so-called session profiles to capture any differences between FIX versions reflected in the value of BeginString(8), e.g. “FIX.4.2” for FIX Version 4.2 and “FIXT.1.1” for FIX Version 5.0 and above. One of the objectives was to add clarity and remove ambiguities. This is a good opportunity to validate that :slight_smile:

The section on Sequence Reset states: A FIX session processor may send a SequenceReset(35=4) message with GapFillFlag(123) set to “N” (Reset) and PossDupFlag(43) set to “Y” to force sequence number synchronization in the peer.

Note the use of PossDupFlag(43) set to “Y” which alerts the counterparty to the fact that he may have received the same MsgSeqNum(34) before. In combination with the SequenceReset(35=4) message I believe it is equivalent to telling the counterparty to ignore the sequence number. The ambiguity may come from the question whether a MsgSeqNum(34) should be validated first and without taking the MsgType(35) value into consideration when deciding upon the action to take.

The refactored specification includes an extensive list of test cases (https://www.fixtrading.org/standards/fix-session-testcases-online/). The test cases for Sequence Reset (Reset), i.e. Scenario 11, state: Accept the SequenceReset(35=4) message without regard to its MsgSeqNum(34).

The publication of the refactored specification in this forum (TECHNICAL STANDARD - FIX Session Protocol) states: “The refactored specification therefore supersedes the aforementioned specifications as the normative reference for the FIX Session Protocol standard.”. Please only make references to or quote from the refactored specification going forward to avoid confusion. The FIX Global Technical Committee will issue errata versions to further clarify the specification. One issue has already been detected (see Confusing MaxMessageSize (383) in the FIXT Online Technical Standard – June 2020).