Hi,
I am facing the following scenario.
My FIX application is sending messages to a FIX counterparty with a certain throttling rate.
After a network disconnection, my FIX application receives a resend request for message X and message X is replayed immediately.
After this event, my fix engine performs a gap fill and the first message to be sent out with new seq number is the content of the message X that was sent out previously but with higher sequence number. I believe this is happening since the message is still hanging in the tcp queue waiting to be transmitted.
So at the end it results in having sent 2 application messages with same content over different sequence numbers.
Is this a correct behaviour? If not, what should be?
Not correct behaviour. If the content was already rendered into message X it should not be sent again as a higher sequence number (at least not without a PossResend flag which should be used sparingly such as recovering from an event when you genuinely have no way to determine what has been sent previously). Correct behaviour is just to resend message X then move on to other things. I don’t know exactly what you mean by “tcp queue”. If you mean some internal application queue then yes you might have a race condition/state management bug where any checks to protect against duplication on entry to the “tcp queue” should be done when draining the queue rather than entry. If you mean the tcp stack itself that’s unlikely to be the cause since that does nothing to determine FIX sequence numbers or protect against application-level duplication (which this is).
1 Like