Sorry, I forgot to mention that quickfix does not send the reject message. Therein lies the bug.

So this is actually fairly easy to detect - see the attached patch. There was another variation where we can collect all the dupes and then throw the error at the end, showing all the dupes. i chose the first one, but we can easily go back to case 2.

Regardless, the behaviour required by OpenFIX certifiation error is much harder to achieve.
They send a message with a dupe in it, and they expect a session-level Reject back.

However, the way this works is that a message comes in to AbstractIoHandler, MessageUtils.parse gets called which calls Message.fromString which will throw an InvalidMessage exception, prints a log error and that's it - this is too low-level a point to send out a session-level reject.

The rejects are sent form Session code itself, and we never get to that point.
If we "ignore" the dupes in the initial parse of the message in AbstracdtIoHandler entrypoint, we lose the fact that we had dupes since we just end up setting the field twice (and losing the previous value). This was the behaviour i was seeing when i was just collecting the dupes into a list, and trying to validate it later (by having another dupeDetection boolean).

So not sure how to handle this case best - if we throw an exception before we get into Session message processing code, we don't send a reject. If we wait until Session code, we've already lost the dupe.

We can, of course, send a reject in the case the message doesn't parse correctly in AbstractIoHandler.messageReceived but i'm not sure of how easy it is to do that since we don't have access to any Session.generateReject code.

thoughts?

I understand the issues. We probably need to wait until after the 1.3.0 release for this one. I'd like some more time to consider the options. Is that ok with you?

Yes, i agree, it's too much of a change to introduce right now.

It's possible to create a "duplicate fields" list that's part of the parsed message, and only validate that it's empty when the codepath is in Session.next() code.
However, even in Session.next(Message msg) function catching an InvalidMessage exception right now only prints a log error and doesn't reject the message, so that'll need to be changed as well.