Incorrect handling of SequenceRest Gap Fill Message

[kmdshuaib]

Hi All,

While performing a message recovery operation in chunks of 2500 messages per resend request,
drop copy gap fills the administrative messages.

Assuming sending "resend request’s” from 10260 till 36264.

1st resend request 10260 till 12759
2nd resend request 12760 till 15259
3rd resend request 15260 till 17759
4th resend request 17760 till 20259

And so on……

While responding the 3rd resend request,
the counter party sends the SequenceReset as there was a gap fill for administrative messages.
However the NewSequence number in that SequenceReset is 36265 (that is actually greater than 3rd resend request end sequence no 17759).

            And then QUICK FIX ignores the next expected resend request itself i.e., 4th  resend request 17760 till 20259

            How should we handle this scenario as such to send the 4th resend request when there is a gapfill towards the end of the resend request response?

Please advice.

[dungvu-equix]

We have same issue, :(

[dungvu-equix]

Here is all msg from server

2015/05/27 17:49:07:836: FIXPump: FIX session established on connection: QECAP
2015/05/27 17:49:07:837: FIXFormatter_QECAP: SENDING RESEND REQUEST - seq# begin: 4026 end: 4034 current: 4026 to: QECAP
2015/05/27 17:49:07:837: FIXConnectionData: Sending data on connection {QECAP} [8=FIX.4.4^A9=0074^A35=2^A49=...^A56=...^A34=4123^A52=20150527-09:49:07^A7=4026^A16=4034^A10=152^A]

2015/05/27 17:49:07:913: FIXPump: Received data on connection {QECAP} [8=FIX.4.4^A9=108^A35=4^A34=4026^A43=Y^A49=...^A52=20150527-09:49:03.971^A56=...^A122=20150527-09:49:03.971^A36=4035^A123=Y^A10=052^A]
2015/05/27 17:49:07:913: FIXPump:QECAP: RECEIVED SequenceReset from 4026 to 4035
2015/05/27 17:49:07:913: FIXPump:QECAP: RECV - Resend Request Done received end seq no 4034

[hungle-qe]

message log client side:

20150527-09:45:37.052 : 8=FIX.4.4�9=91�35=0�34=4025�49=Client�52=20150527-09:45:37.052�56=Server�112=Appia-20150527-09:45:40�10=160�
20150527-09:45:40.313 : 8=FIX.4.4�9=235�35=D�34=4026�49=Client�52=20150527-09:45:40.313�56=Server�1=CS555A�11=197360340051�15=USD�21=1�22=5�38=4�40=2�44=126.3�48=1730�49=Client�54=2�55=KC�59=0�107=3�115=�116=Client�200=201507�207=IEPA�461=FXXXXX�513=TCB038001�10=163�
20150527-09:46:12.043 : 8=FIX.4.4�9=75�35=A�34=4027�49=Client�52=20150527-09:46:12.043�56=Server�98=0�108=10�10=111�
20150527-09:46:42.463 : 8=FIX.4.4�9=75�35=A�34=4028�49=Client�52=20150527-09:46:42.463�56=Server�98=0�108=10�10=121�
20150527-09:46:46.691 : 8=FIX.4.4�9=235�35=D�34=4029�49=Client�52=20150527-09:46:46.691�56=Server�1=CS555A�11=197360406445�15=USD�21=1�22=5�38=3�40=2�44=1633�48=1779�49=Client�54=1�55=LRC�59=0�107=3�115=�116=Client�200=201511�207=IEPA�461=FXXXXX�513=TCB011001�10=227�
20150527-09:47:12.883 : 8=FIX.4.4�9=75�35=A�34=4030�49=Client�52=20150527-09:47:12.883�56=Server�98=0�108=10�10=118�
20150527-09:47:43.303 : 8=FIX.4.4�9=75�35=A�34=4031�49=Client�52=20150527-09:47:43.303�56=Server�98=0�108=10�10=110�
20150527-09:48:13.723 : 8=FIX.4.4�9=75�35=A�34=4032�49=Client�52=20150527-09:48:13.723�56=Server�98=0�108=10�10=115�
20150527-09:48:13.801 : 8=FIX.4.4�9=0071�35=A�49=Server�56=Client�34=4119�52=20150527-09:48:17�98=0�108=10�10=015�
20150527-09:48:13.801 : 8=FIX.4.4�9=75�35=2�34=4033�49=Client�52=20150527-09:48:13.801�56=Server�7=4115�16=0�10=096�
20150527-09:48:13.801 : 8=FIX.4.4�9=0074�35=2�49=Server�56=Client�34=4120�52=20150527-09:48:17�7=4022�16=4031�10=142�
20150527-09:48:13.801 : 8=FIX.4.4�9=108�35=4�34=4022�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�122=20150527-09:48:13.801�36=4026�123=Y�10=032�
20150527-09:48:13.801 : 8=FIX.4.4�9=266�35=D�34=4026�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�115=�116=Client�122=20150527-09:45:40.313�1=CS555A�11=197360340051�15=USD�21=1�22=5�38=4�40=2�44=126.3�48=1730�54=2�55=KC�59=0�107=3�200=201507�207=IEPA�461=FXXXXX�513=TCB038001�10=175�
20150527-09:48:13.801 : 8=FIX.4.4�9=108�35=4�34=4027�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�122=20150527-09:48:13.801�36=4029�123=Y�10=040�
20150527-09:48:13.801 : 8=FIX.4.4�9=266�35=D�34=4029�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�115=�116=Client�122=20150527-09:46:46.691�1=CS555A�11=197360406445�15=USD�21=1�22=5�38=3�40=2�44=1633�48=1779�54=1�55=LRC�59=0�107=3�200=201511�207=IEPA�461=FXXXXX�513=TCB011001�10=239�
20150527-09:48:13.801 : 8=FIX.4.4�9=108�35=4�34=4030�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�122=20150527-09:48:13.801�36=4032�123=Y�10=028�
20150527-09:48:13.833 : 8=FIX.4.4�9=0100�35=4�49=Server�56=Client�34=4115�43=Y�122=20150527-09:48:17�52=20150527-09:48:17�36=4121�123=Y�10=193�
20150527-09:48:13.833 : 8=FIX.4.4�9=0105�35=3�49=Server�56=Client�34=4121�52=20150527-09:48:17�45=4026�58=Framing error: Checksum not found.�10=117�
20150527-09:49:03.909 : 8=FIX.4.4�9=75�35=A�34=4035�49=Client�52=20150527-09:49:03.877�56=Server�98=0�108=10�10=128�
20150527-09:49:03.940 : 8=FIX.4.4�9=0071�35=A�49=Server�56=Client�34=4122�52=20150527-09:49:07�98=0�108=10�10=009�
20150527-09:49:03.971 : 8=FIX.4.4�9=0074�35=2�49=Server�56=Client�34=4123�52=20150527-09:49:07�7=4026�16=4034�10=152�
20150527-09:49:03.971 : 8=FIX.4.4�9=108�35=4�34=4026�43=Y�49=Client�52=20150527-09:49:03.971�56=Server�122=20150527-09:49:03.971�36=4035�123=Y�10=052�
20150527-09:49:04.080 : 8=FIX.4.4�9=235�35=D�34=4036�49=Client�52=20150527-09:49:04.080�56=Server�1=CS555A�11=197360539858�15=USD�21=1�22=5�38=1�40=2�44=150.5�48=1730�49=Client�54=2�55=KC�59=0�107=3�115=�116=Client�200=201507�207=IEPA�461=FXXXXX�513=TCB038001�10=190�

[dungvu-equix]

                                                                                  Seem like the issue come when receive 2 or more msg reset seq from acceptor. We will try to simulate this issue again.                                                                                                                                                                                                                                                                                                                                        -- Dung Vu | Developer | Amigo Quant Edge JSCmobile: +849 0896 6639email: dung.vu@quant-edge.comskype: dung.vtAmigo Quant Edge JSCSuite #503, IPH Building241 Xuan Thuy Street, Cau Giay DistHanoi, Vietnamtel: +84 (4) 7300 8999fax: +84 (4) 7300 3999web: www.quant-edge.comThis message (including attachments, if any) is confidential, may be privileged and is intended for the above-named recipient(s) only. If you have received this message in error, please notify me by return email and delete this message from your system. Any unauthorized use or disclosure of this message is strictly prohibited.Amigo Quant Edge JSC assumes no responsibility for errors, inaccuracies or omissions in these materials, and does not warrant the accuracy or completeness of the information contained within these materials. Amigo Quant Edge JSC shall not be liable for any special, indirect, incidental, or consequential damages, including without limitation losses, lost revenues, or lost profits that may result from these materials.                                                                                                                                                                                                                From: hungle-qeSent: Thursday, May 28, 2015 18:43To: connamara/quickfixnReply To: connamara/quickfixnCc: Dung VuSubject: Re: [quickfixn] Incorrect handling of SequenceRest Gap Fill Message (#309)message log client side:

20150527-09:45:37.052 : 8=FIX.4.4�9=91�35=0�34=4025�49=Client�52=20150527-09:45:37.052�56=Server�112=Appia-20150527-09:45:40�10=160�
20150527-09:45:40.313 : 8=FIX.4.4�9=235�35=D�34=4026�49=Client�52=20150527-09:45:40.313�56=Server�1=CS555A�11=197360340051�15=USD�21=1�22=5�38=4�40=2�44=126.3�48=1730�49=Client�54=2�55=KC�59=0�107=3�115=�116=Client�200=201507�207=IEPA�461=FXXXXX�513=TCB038001�10=163�
20150527-09:46:12.043 : 8=FIX.4.4�9=75�35=A�34=4027�49=Client�52=20150527-09:46:12.043�56=Server�98=0�108=10�10=111�
20150527-09:46:42.463 : 8=FIX.4.4�9=75�35=A�34=4028�49=Client�52=20150527-09:46:42.463�56=Server�98=0�108=10�10=121�
20150527-09:46:46.691 : 8=FIX.4.4�9=235�35=D�34=4029�49=Client�52=20150527-09:46:46.691�56=Server�1=CS555A�11=197360406445�15=USD�21=1�22=5�38=3�40=2�44=1633�48=1779�49=Client�54=1�55=LRC�59=0�107=3�115=�116=Client�200=201511�207=IEPA�461=FXXXXX�513=TCB011001�10=227�
20150527-09:47:12.883 : 8=FIX.4.4�9=75�35=A�34=4030�49=Client�52=20150527-09:47:12.883�56=Server�98=0�108=10�10=118�
20150527-09:47:43.303 : 8=FIX.4.4�9=75�35=A�34=4031�49=Client�52=20150527-09:47:43.303�56=Server�98=0�108=10�10=110�
20150527-09:48:13.723 : 8=FIX.4.4�9=75�35=A�34=4032�49=Client�52=20150527-09:48:13.723�56=Server�98=0�108=10�10=115�
20150527-09:48:13.801 : 8=FIX.4.4�9=0071�35=A�49=Server�56=Client�34=4119�52=20150527-09:48:17�98=0�108=10�10=015�
20150527-09:48:13.801 : 8=FIX.4.4�9=75�35=2�34=4033�49=Client�52=20150527-09:48:13.801�56=Server�7=4115�16=0�10=096�
20150527-09:48:13.801 : 8=FIX.4.4�9=0074�35=2�49=Server�56=Client�34=4120�52=20150527-09:48:17�7=4022�16=4031�10=142�
20150527-09:48:13.801 : 8=FIX.4.4�9=108�35=4�34=4022�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�122=20150527-09:48:13.801�36=4026�123=Y�10=032�
20150527-09:48:13.801 : 8=FIX.4.4�9=266�35=D�34=4026�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�115=�116=Client�122=20150527-09:45:40.313�1=CS555A�11=197360340051�15=USD�21=1�22=5�38=4�40=2�44=126.3�48=1730�54=2�55=KC�59=0�107=3�200=201507�207=IEPA�461=FXXXXX�513=TCB038001�10=175�
20150527-09:48:13.801 : 8=FIX.4.4�9=108�35=4�34=4027�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�122=20150527-09:48:13.801�36=4029�123=Y�10=040�
20150527-09:48:13.801 : 8=FIX.4.4�9=266�35=D�34=4029�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�115=�116=Client�122=20150527-09:46:46.691�1=CS555A�11=197360406445�15=USD�21=1�22=5�38=3�40=2�44=1633�48=1779�54=1�55=LRC�59=0�107=3�200=201511�207=IEPA�461=FXXXXX�513=TCB011001�10=239�
20150527-09:48:13.801 : 8=FIX.4.4�9=108�35=4�34=4030�43=Y�49=Client�52=20150527-09:48:13.801�56=Server�122=20150527-09:48:13.801�36=4032�123=Y�10=028�
20150527-09:48:13.833 : 8=FIX.4.4�9=0100�35=4�49=Server�56=Client�34=4115�43=Y�122=20150527-09:48:17�52=20150527-09:48:17�36=4121�123=Y�10=193�
20150527-09:48:13.833 : 8=FIX.4.4�9=0105�35=3�49=Server�56=Client�34=4121�52=20150527-09:48:17�45=4026�58=Framing error: Checksum not found.�10=117�
20150527-09:49:03.909 : 8=FIX.4.4�9=75�35=A�34=4035�49=Client�52=20150527-09:49:03.877�56=Server�98=0�108=10�10=128�
20150527-09:49:03.940 : 8=FIX.4.4�9=0071�35=A�49=Server�56=Client�34=4122�52=20150527-09:49:07�98=0�108=10�10=009�
20150527-09:49:03.971 : 8=FIX.4.4�9=0074�35=2�49=Server�56=Client�34=4123�52=20150527-09:49:07�7=4026�16=4034�10=152�
20150527-09:49:03.971 : 8=FIX.4.4�9=108�35=4�34=4026�43=Y�49=Client�52=20150527-09:49:03.971�56=Server�122=20150527-09:49:03.971�36=4035�123=Y�10=052�
20150527-09:49:04.080 : 8=FIX.4.4�9=235�35=D�34=4036�49=Client�52=20150527-09:49:04.080�56=Server�1=CS555A�11=197360539858�15=USD�21=1�22=5�38=1�40=2�44=150.5�48=1730�49=Client�54=2�55=KC�59=0�107=3�115=�116=Client�200=201507�207=IEPA�461=FXXXXX�513=TCB038001�10=190�

—Reply to this email directly or view it on GitHub.

[dungvu-equix]

After 2-3 request reset msg: the initator store.get() return list msg with count = 0. We dont know why, and try to re-make this case again.

[oclancy]

Original report is from a while ago but I have recreated this issue.

Basically as OP states the GapFill=Y causes the SequenceReset Verify call to fail:

Below the ResendRequest was for 17907 to 0 (last seen message was 19102), Next expected Sequence number is therefore 19103.

The last 4 messages of the resend are (trade info redacted):
20230712-15:37:43.309 : 8=FIX.4.2 | 9=416 | 35=8 | 122=20230712-15:32:14.946 | 56=COMPID1 | 52=20230712-15:32:40.709 | 49=COMPID2 | 43=Y | 34=19101 | 120=USD | 151=xxxx | 150=1 | 39=1 | 38=xxxx | 37=xxxx | 32=xx | 167=CS | 31=xxxx | 60=20230712-15:32:14.867 | 17=xxxx | 48=xxxx | 15=xxxx | 14=xx | 76=xxxx | 44=0 | 75=20230712 | 11=xxxxx | 40=1 | 7504=xxxx | 59=0 | 7500=xxxx | 207=x | 6=xxxxx | 55=xxxx | 54=2 | 22=5 | 1=xxxx | 21=2 | 20=0 | 10=242 |

19103 was an admin message so gap fill sent to cover and set next seq num to 19104
20230712-15:37:43.695 : 8=FIX.4.2 | 9=103 | 35=4 | 52=20230712-15:32:40.709 | 49=COMPID2 | 34=19102 | 56=COMPID1 | 43=Y | 36=19104 | 123=Y | 10=145 |

Next msg (19104) received
20230712-15:37:43.852 : 8=FIX.4.2 | 9=417 | 35=8 | 122=20230712-15:32:39.040 | 56=COMPID1 | 52=20230712-15:32:40.709 | 49=COMPID2 | 43=Y | 34=19104 | 120=USD | 151=xxxx | 150=1 | 39=1 | 38=xxxx | 37=xxxx | 32=xx | 167=CS | 31=xxxx | 60=20230712-15:32:15.562 | 17=xxxxx | 48=xxxx | 15=xxxx | 14=xx | 76=xxxx | 44=0 | 75=20230712 | 11=xxxxx | 40=1 | 7504=xxxx | 59=0 | 7500=xxxx | 207=x | 6=xxxxx | 55=xxxx | 54=5 | 22=5 | 1=xxxx | 21=2 | 20=0 | 10=144 |

Due to fault in Session.Verify for SequenceReset messages, NewSeqNo will not be set (from SequenceReset message above), and a new ResendRequest is generated.
20230712-15:37:44.281 : 8=FIX.4.2 | 9=95 | 35=2 | 34=1376 | 49=COMPID1 | 52=20230712-15:37:44.096 | 56=COMPID2 | 7=**19103** | 16=0 | 10=188 |

The next SequenceReset message received will actually have the next expected msgseqnum (19103 in this case) and Session.Verify will return true at which point then the NewSeqNo(36) will be acted upon.

The problem I have is that with very heavy message flow, once the first resend is satisfied, the Sender then continues to send stored up messages at which point it then recieves the second ResendRequest (generated in error) and causes a large cycle of resends which can kill the connection.

I will create a PR if I can rationalise a fix