Hi all,
Recently I’ve seen a scenario where a bad message triggered a session level reject which then triggered another session level reject because the cause of the reject was not a valid reject reason in the version of FIX being used.
Obviously the immediate fixes are obvious, but my question is, should an invalid Session Level Reject actually be responded to by a Session Level Reject. In my case it was fine because we only saw 2. But it could have potientially triggered a neverending cascade of failures, each side rejecting the other side’s reject.
The current FIXT spec implies that any message can be rejected. However, it makes less sense for session level messages (LOGON is easier to handle with just a LOGOUT) and certainly for 35=3 it seems dangerous to be trying to reject a reject. I’m wondering whether the spec meant ‘application messages’. It’s not clear that a FIX engine could reasonably handle a Reject for a ResendRequest either for example.
What do you do in this scenario?
Session level rejecting a session level reject could lead to a never ending series of session level rejects, if the that session level reject is in turn rejected, and so on, etc. I would avoid session level rejecting a session level reject.
Hi!
If FIX Engine will not reject a session-level reject, counterparty never will know that its reject was not processed. For example, buy-side sends an incorrect order. Sell-side rejects this order with session-level reject. Buy-side cannot process a reject. If buy-side will not reject a reject, this means that buy-side do not know that order was rejected and sell-side do not know that buy-side has a problem with reject processing. As for me, it is much preferable to implement logic like “send a logout if reject is rejected”.
Sending a logoff doesn’t seem like the ideal solution. Especially if the one sending the logout is the acceptor - the initiator will just reconnect and it will appear normal.
I agree that the side choosing not to reject a reject should instead raise an alert with whatever monitoring is in place to ensure the situation is resolved.
I think if you can tell it’s a reject enough to not send a second reject you should have enough to ensure that whatever monitoring you have can be appropriately informed.
I don’t think just logging out is a good solution.
Session Level Rejects (and for that fact BMRs) have been and continue to be a pain in FIX (in particular when in FIX-to-FIX routing situations). Most of the time they cause more problems as a consequence, as described here.
I would treat Session Level Rejects as fatal protocol exceptions, that means: logout if possible with a good reason and then block the session from further logon attempts (that goes for both, initator and acceptor)
Unfortunately, hardly any FIX engine (if any at all, non to my knowledge) come with this functionality built-in. So you will have to add this yourself, but that’s fairly simple to do.
1 Like
Logging out and preventing the FIX connection from reconnecting, may work for some applications. But wouldn’t work for many applications.
It would require manual attention to resolve, which could take 10s of minutes to resolve. It could result in an application being knocked out a market for 10s of minutes and not able to replace, cancel, or add orders across all their orders & markets, due to an issue with 1 order or message.
This might work for an application which is used by a single company, but likely wouldn’t work for an application receiving flow from many different companies and sources.
1 Like