CODEWITHSUNDEEP
quickfixquickfixn
rupweb
rupweb

Reputation: 3328

quickfixn executionreport 35=8 in message log but didn't hit fromapp or crack

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) 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?

enter image description here

Upvotes: 1

Views: 1009

Answers (2)

rupweb
rupweb

Reputation: 3328

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.

Upvotes: 1

Grant Birchmeier
Grant Birchmeier

Reputation: 18504

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?

Upvotes: 1

Related Questions