消息日志中的quickfixn执行报告35 = 8，但未从应用程序或破解中被击中

Question

So we send a FIX deal message without a side, and the bank rejects with a 35=8 execution report with 150=8 reject, and text FIX Tag 54 (Side) has invalid value (0). Reason (should be either 1 or 2) FIX Tag 54 (Side) has invalid value (0). Reason (should be either 1 or 2) and then a 35=3 reject message with Value is incorrect (out of range) for this tag . The 35=3 message is cracked but the 35=8 message never gets to fromapp.

Am I missing a setting?

Answer 1

35=3 indicates a transport-level (aka admin-level) reject. The message was rejected at a lower parsing layer, which means that it's so malformed that it wasn't even passed up to your application.

Usually this kind of reject means that the message was messed up in a way such that the engine can't even parse it correctly, or that the header fields can't resolve to a known session. I'm a little surprised that your particular situation triggered a 35=3 instead of a 35=j.

I suppose you could check the FIX spec to see what it mandates when an enum-type tag has an unknown value. Maybe the engine is following spec in this case?

Answer 2

I guess the reason why the 35=8 message with the incorrect 54=0 tag doesn't get to FromApp or FromAdmin is because of a data dictionary constraint, but this gave me a chance to implement the public void FromEarlyIntercept(Message msg, SessionID s) interface, and that has solved the problem that a bad 35=8 report is now reported back to the user... but introduced a new problem that a good report is now reported twice.

So I added <value enum="0" description="ERROR"/> to the enumeration for <field number="54" name="Side" type="CHAR"> and now the 35=8 message is not rejected by a 35=3 message.