Processing of Test Request in case of gap in SeqNum

, ,
1

Imported from previous forum

2

Dear All,

I have a question about correct processing of Test Request message (FIX 4.4 version is used).

Scenario is below:

  1. Party A expects Logon with MsgSeqNum = 1.
  2. Party B sends Logon with MsgSeqNum = 57.
  3. Party B immediately sends Test Request with MsgSeqNum = 58.
  4. Party A sends confirming Logon.
  5. Party A sends Resend Request with BeginSeqNo = 1, EndSeqNo = 0 (what means infinity).
  6. Party B sends Sequence Reset with GapFill = Y and NewSeqNo = 59.

Received Sequence Reset message shows that gap is filled, and Party A should expect next message with MsgSeqNum = 59.

But what is correct behaviour of Party A regarding Test Request with MsgSeqNum = 58?
It looks like it should be ignored because gap is already filled.
But what if Party B still waits for Heartbeat with corresponding TestReqID?

Could you please advise?

Thank you in advance.

3

[ original email was from John Prewett - jprewett@lavatrading.com ]
I have encountered this issue before.
I believe:

  1. A should ignore the out-of-sequence TestRequest as it is using the “thru infinity” method of handling sequence number gaps. The subsequent gap-fill it receives doesn’t force it to take any action.

  2. B should be aware that a response to the TestRequest won’t be forthcoming because it received and responded to a ResendRequest which included the MsgSeqNum of the TestRequest message.

So if B is waiting for a response to the gap-filled TestRequest, it is making a mistake.

JohnP

Dear All,

I have a question about correct processing of Test Request message (FIX
4.4 version is used).

Scenario is below:

  1. Party A expects Logon with MsgSeqNum = 1.
  2. Party B sends Logon with MsgSeqNum = 57.
  3. Party B immediately sends Test Request with MsgSeqNum = 58.
  4. Party A sends confirming Logon. 5) Party A sends Resend Request with
    BeginSeqNo = 1, EndSeqNo = 0 (what means infinity).
  5. Party B sends Sequence Reset with GapFill = Y and NewSeqNo = 59.

Received Sequence Reset message shows that gap is filled, and Party A
should expect next message with MsgSeqNum = 59.

But what is correct behaviour of Party A regarding Test Request with
MsgSeqNum = 58? It looks like it should be ignored because gap is
already filled. But what if Party B still waits for Heartbeat with
corresponding TestReqID?

Could you please advise?

Thank you in advance.

4

Hi All,

I would also state that B immediately sending a test request is not an elegant practice. B should ideally wait for the logon-ack before it sends out any messages OR wait some amount of time before it starts sending out new / queued messages.

As John stated, the test request can be (and have to be) now ignored by A. I would suggest the corrective action to take place on B’s side to wait for the logon-ack which is what is stipulated in FIX as well

Thaya.

Dear All,

I have a question about correct processing of Test Request message (FIX
4.4 version is used).

Scenario is below:

  1. Party A expects Logon with MsgSeqNum = 1.
  2. Party B sends Logon with MsgSeqNum = 57.
  3. Party B immediately sends Test Request with MsgSeqNum = 58.
  4. Party A sends confirming Logon. 5) Party A sends Resend Request with
    BeginSeqNo = 1, EndSeqNo = 0 (what means infinity).
  5. Party B sends Sequence Reset with GapFill = Y and NewSeqNo = 59.

Received Sequence Reset message shows that gap is filled, and Party A
should expect next message with MsgSeqNum = 59.

But what is correct behaviour of Party A regarding Test Request with
MsgSeqNum = 58? It looks like it should be ignored because gap is
already filled. But what if Party B still waits for Heartbeat with
corresponding TestReqID?

Could you please advise?

Thank you in advance.

5

Thank you all for answers!