(@HannoKlein I did read your view for the similar query before but I cannot locate that query again so I put down my new query here - I am sorry about this. Also I am sorry that my query is quite long. Actually, I am now reviewing our FIX parser and it needs to decide which 373(SessionRejectReason) should be returned)
Consider the following case about the parsing on a repeating group:
-
Let’s use the Parties repeating group. Assume a FIX engine receives the following Parties tags:
453(NoPartyIDs)=1
448(PartyID)=ABC
447(PartyIDSource)=D
452(PartyRole)=3
448(PartyID)=DEF <- this one violates FIX requirement (where 448 is the first tag after 453)
-
The 448(PartyID)=DEF does violates FIX requirement and Session Reject will be returned. In the Session Reject, what enum will the 373(SessionRejectReason) carry? I believe we can choose from:
- 16=Incorrect NumInGroup count for repeating group
- 2=Tag not defined for this message type
-
How about for the following message - which 373(SessionRejectReason) will be returned:
453(NoPartyIDs)=1
448(PartyID)=ABC
447(PartyIDSource)=D
452(PartyRole)=3
447(PartyIDSource)=E <- this one violates FIX requirement (where 447 is the second tag after 453)
-
Actually, I’ve checked the QuickFix and OnixS, they will return “16=Incorrect NumInGroup count for repeating group”; Anyway, as far as I know, some other FIX engines (used by some exchanges) will return “2=Tag not defined for this message type”.
-
Which one (16 or 2) is more right?
(From my point of view, I think “2=Tag not defined for this message type” is better. My rational is as below:
When a FIX parser starts to parse the message, it will encounter the 453=1 first. It will then mark down the no. of repeating times equal to 1. When it encounters the 452, it knows the repeating group has been ended and exits the repeating group. It then encounters the 448(PartyID)=DEF. At this moment, the FIX parse has no knowledge about the Parties repeating group and therefore “2=Tag not defined for this message type” is returned which is straightforward.
My another reason is that let’s assume the following message is received:
453(NoPartyIDs)=1
448(PartyID)=ABC
447(PartyIDSource)=D
452(PartyRole)=3
11(ClOrdID)=12346
…
447(PartyIDSource)=E <- this one violates FIX requirement(where its position is totally away from/separated from the Parties repeating group)
Then, which enum (16 or 2) should be returned? I also think 2 is better and this is consistent.)
I don’t know how other FIX engines handle this but at least QFJ does not act upon the last field of a repeating group. The group parsing either ends when encountering a field that is not part of the group or encountering a new delimiter which starts parsing of the next instance of the group.
Edit: moreover I think as long as FIX engines recognise the error both enums should be fine.
Also maybe reason “Out of order repeating group members” would be more appropriate in my opinion.
I disagree that “2” is the one to use. “2” means exactly as that description "tag not defined for this message type - in other words the parser came across a field that is NOT defined as part of the message type it is parsing. If the message type is defined to have a Parties component then tag 448 is very valid. For me if 453=1 is what you got but you got an exact 448, I’d use “16”.
This would be a serious anomaly with your counterparty’s implementation. For me this is more accurated rejected with a “15” (Repeating group fields out of order) as @christophjohn pointed out.
I can’t speak for what FIX engines do today, but back in my days testing and onboarding FIX engines use the first field of the repeating group as the delimiter. The FIX Session specification states as such as well that the first field of repeating group’s definition is the instance delimiter with this statement because the first field is always required if the repeating group’s NumInGrp field is 1 or greater:
This is not a “2”. Again if the Parties component is defined in the message type you’re using it is a valid field. This is more accurately a “15”.
Rejection reasons is not about “consistency” but about exact reason of why something is rejected.
1 Like
Thanks christophjohn & Itaikit. I see your points and agreed with this:
Rejection reasons is not about “consistency” but about exact reason of why something is rejected
For those who are interested in this topic - Just conducted more tests on QuickFix(C++) and its behaviour is as below:
The following will result in “Tag not defined for this message type”
1128=9
452=2
11=2
453=1
448=4403
447=D
452=2
48=1
22=8
The following will result in “Tag not defined for this message type”
453=1
448=4403
447=D
452=2
48=1
22=8
207=XHKG
40=2
54=1
38=10000
44=100
452=2
60=20200325-08:52:37.895
The following will result in “Repeating group count mismatch”
11=2
453=1
448=4403
447=D
452=2
452=2
48=1
The following will result in “Repeating group count mismatch”
1128=9
11=2
453=1
448=4403
447=D
452=2
447=D
48=1
The following will result in “Repeated tag not part of repeating group”
11=2
453=1
448=4403
447=D
452=2
453=1
48=1