-
Notifications
You must be signed in to change notification settings - Fork 566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
issue with Hop groups in allocation instruction J #313
Comments
Did the thrown exception crash the engine? That would definitely be a bug. |
Hello, |
Here's a unit test that reproduces the issue (added to DataDictionaryTests.cs). I think this is related to the NoHops group in the header. It's the only repeating group that is defined in the StandardHeader, and there is no test that includes this field. It may be entirely possible that nobody has ever used QF/n to receive a message that includes NoHops! (Seriously, who uses NoHops? I don't even know what it's for.) Here's a test that reproduces your issue (added to DataDictionaryTests.cs).
I think I'm on the way to a fix. |
Hello, the exception triggers a disconnect:
Regards, |
Yes, it's well understood now, I just need to make time to fix it. |
It chokes on this line in DataDictionary.cs
In that line, msgType=J and groupTag=627 (NoHops). The choke is inside the To do this totally correctly, we should probably switch to a generated Header class, rather than this janky hardcoded one that defines no fields and has no typesafe methods. I'm not really excited about writing that, because I'll have to generate separate headers for FIX41,FIX42,etc and I'm worried about side effects. Could be easy, could be a rabbit hole. |
Hi,
when receiving the hereunder allocation instruction (parties were renamed so length and hash are no longer consistent) on our quickfix server, an exception was thrown (see hereunder complete stack) , due to a bad index search in a dictionary.
Exception is thrown from file DataDictionary\DataDictionary.cs in method
Faulty Code section is :
This loop is looking for groupTag 627 in Messages["J"] and this throws the exception.
Adding a condition
before the GetGroup() line solves the issue, but i wonder if it might hide a deeper issue ?
regards
Xavier
Exception stack :
FIX message :
The text was updated successfully, but these errors were encountered: