Bite Apps › SafeFIX › FIX session troubleshooting

FIX session troubleshooting — logon, sequence numbers, resends and heartbeats

Why FIX sessions drop, loop on resends or refuse to log on: how Logon, MsgSeqNum, ResendRequest, SequenceReset gap fill and heartbeats work, a table of common symptoms with their causes, and a worked example of a gap recovery.

• Session basics
• Logon
• Sequence numbers
• ResendRequest and gap fill
• Heartbeats and TestRequest
• Symptoms and fixes
• Example: recovering a gap

Session basics

A FIX session is identified by BeginString (8), SenderCompID (49) and TargetCompID (56). Each side numbers the messages it sends with MsgSeqNum (34), starting at 1 at the beginning of a session (usually once a day, by schedule) and incrementing by one per message, administrative messages included. Each side persists both its next outgoing and next expected incoming number. Almost every session problem is a disagreement about one of these two numbers, the CompIDs or the heartbeat.

Logon

The initiator sends Logon with its HeartBtInt; the acceptor validates CompIDs, credentials and the sequence number and replies with its own Logon. If the MsgSeqNum of the Logon is higher than expected, the receiver first accepts the Logon and then sends a ResendRequest; if it is lower, the receiver logs out (or simply disconnects) because messages would be lost silently. ResetSeqNumFlag (141=Y) on Logon asks both sides to start again at 1 — both Logon messages then carry 34=1 and 141=Y. NextExpectedMsgSeqNum (789), available from FIX 4.4, tells the other side which number you expect next so that gaps can be resolved during logon.

Sequence numbers

ResendRequest and gap fill

A ResendRequest gives BeginSeqNo (7) and EndSeqNo (16); since FIX 4.2, EndSeqNo 0 means “everything after BeginSeqNo” (FIX 4.0 and 4.1 used 999999). The sender replays application messages from its store with PossDupFlag=Y, the original MsgSeqNum and OrigSendingTime. Administrative messages (Logon, Logout, Heartbeat, TestRequest, ResendRequest, SequenceReset) are never resent: the sender replaces each run of them — and any application messages it decides not to resend, such as orders that are too old to act on — with a SequenceReset with GapFillFlag=Y whose MsgSeqNum is the first skipped number and whose NewSeqNo is the next number that follows. SequenceReset with GapFillFlag=N (or absent) is a hard reset: it sets the receiver's expected number to NewSeqNo regardless of gaps, may only move the number forward, and is meant for disaster recovery.

Heartbeats and TestRequest

Both sides send a Heartbeat whenever they have sent nothing for HeartBtInt seconds. When a side has received nothing for HeartBtInt plus a reasonable transmission allowance (often 20%), it sends a TestRequest with a TestReqID; the answer must be a Heartbeat carrying the same TestReqID (112). If that does not arrive within another interval, the connection is considered lost and should be closed. The HeartBtInt is agreed in the Logon messages and should be the same on both sides.

Symptoms and fixes

Example: recovering a gap

The counterparty expects 101 but our side logs on with 105 (four messages were sent while their side was down):

us   → 35=A  34=105  108=30
them → 35=A  34=88   108=30
them → 35=2  34=89   7=101  16=104                  (ResendRequest: 101 to 104)
us   → 35=4  34=101  43=Y  123=Y  36=103            (gap fill: 101–102 were administrative)
us   → 35=D  34=103  43=Y  122=20261112-08:15:02.120 (resent NewOrderSingle)
us   → 35=F  34=104  43=Y  122=20261112-08:15:09.004 (resent OrderCancelRequest)
us   → 35=0  34=106                                  (normal traffic continues after the Logon's 105)

Logs like this are where most session problems are found. SafeFIX reads them in the browser — sequence numbers, PossDupFlag, rejects and the order lifecycle side by side — without uploading them.

FAQ

Last updated 2026-11-12. Something wrong or missing? Email support@biteapps.cc.