# Rejection Loop **URL:** \ **Category:** General Q&A\ **Tags:** imported, 40-session, xid\_164780\ **Created:** [September 4, 2007, 1:59pm UTC](https://forum.fixtrading.org/t/rejection-loop/13128 "2007-09-04T13:59:23Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![evaschmidt\_x](https://avatars.discourse-cdn.com/v4/letter/e/c68b51/32.png) [@evaschmidt\_x](https://forum.fixtrading.org/u/evaschmidt_x)\ **Post date:** [September 4, 2007, 1:59pm UTC](https://forum.fixtrading.org/t/rejection-loop/13128/1 "2007-09-04T13:59:23Z")
Imported from previous forum ---
**Author:** ![evaschmidt\_x](https://avatars.discourse-cdn.com/v4/letter/e/c68b51/32.png) [@evaschmidt\_x](https://forum.fixtrading.org/u/evaschmidt_x)\ **Post date:** [September 4, 2007, 1:59pm UTC](https://forum.fixtrading.org/t/rejection-loop/13128/2 "2007-09-04T13:59:23Z")
Hello, I had the following problem and don’t really know how it should be handled: First I send an order which is rejected for any reason, for example “Unknown instrument”. My counterparty sends me an ExecutionReport with this information, but due to the unknown instrument the value in tag “Symbol” (55) is empty. On my side this leads to a Reject Message. So far so good. But: The ExecutionReport has been received, but not really handled, so I don’t increment the incoming SequenceNumber. Due to this, my application sends a ResendRequest and the whole game starts again… The result is a never-ending loop with ResendRequest - ExecutionReport - Reject - SequenceReset … In my opinion, the counterparty should react somehow to my Reject Message. Or at least doesn’t resend the faulty ExecutionReport. Does anybody had the same problem before or any ideas how I should solve this? The FIX 4.2 Specification tells only that “there should be some logic…” 😉 : “Note: The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop, which may be encountered in this situation.” Thanks for any help or ideas! Eva ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [September 4, 2007, 3:17pm UTC](https://forum.fixtrading.org/t/rejection-loop/13128/3 "2007-09-04T15:17:03Z")
[original email was from Greg Orsini - [greg.orsini@orcsoftware.com](mailto:greg.orsini@orcsoftware.com) ] Eva, You should increment the next expected sequence number when rejecting an incoming message. You should not be sending the resend request in your scenario. From the FIX 4.0 & 4.2 specs: The reject message should be issued when a message is received which cannot be passed through to the application level. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. MsgType=&) which successfully passes de-encryption, CheckSum and BodyLength checks. (As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.) Rejected messages should be logged and the incoming sequence number incremented. Regards, Greg. > Hello, > > I had the following problem and don’t really know how it should > be handled: > > First I send an order which is rejected for any reason, for example > “Unknown instrument”. My counterparty sends me an ExecutionReport with > this information, but due to the unknown instrument the value in tag > “Symbol” (55) is empty. On my side this leads to a Reject Message. > > So far so good. But: The ExecutionReport has been received, but not > really handled, so I don’t increment the incoming SequenceNumber. Due to > this, my application sends a ResendRequest and the whole game starts > again… The result is a never-ending loop with ResendRequest - > ExecutionReport - Reject - SequenceReset … > > In my opinion, the counterparty should react somehow to my Reject > Message. Or at least doesn’t resend the faulty ExecutionReport. > > Does anybody had the same problem before or any ideas how I should > solve this? > > The FIX 4.2 Specification tells only that “there should be some > logic…” 😉 : > > “Note: The receiving application should disregard any message that is > garbled, cannot be parsed or fails a data integrity check. Processing of > the next valid FIX message will cause detection of a sequence gap and a > Resend Request will be generated. Logic should be included in the FIX > engine to recognize the possible infinite resend loop, which may be > encountered in this situation.” > > Thanks for any help or ideas! Eva ---
**Author:** ![evaschmidt\_x](https://avatars.discourse-cdn.com/v4/letter/e/c68b51/32.png) [@evaschmidt\_x](https://forum.fixtrading.org/u/evaschmidt_x)\ **Post date:** [September 4, 2007, 3:45pm UTC](https://forum.fixtrading.org/t/rejection-loop/13128/4 "2007-09-04T15:45:40Z")
Hello Greg, indeed I I have to Sequence Numbers in my system: SeqNum\_rcvd und SeqNum\_done. Indeed the SeqNum\_rcvd will be incremented also in case of rejection. But I’m not sure if I also shall increment the SeqNum\_done - finally the message is not handled correctly. So in fact it’s the question how to react correctly. To loop is wrong, sure. But is it more correct to just ignore and log the message that couldn’t be handled? Maybe this leads to some other unexpected effects… Or does it make sense to close the connection in this case with an error? Maybe I’m overestimating this case but maybe it’s worth to discuss it a little bit? Bye Eva > Eva, > > You should increment the next expected sequence number when rejecting > an incoming message. You should not be sending the resend request in > your scenario. > > From the FIX 4.0 & 4.2 specs: > > The reject message should be issued when a message is received which > cannot be passed through to the application level. An example of when a > reject may be appropriate would be the receipt of a message with invalid > basic data (e.g. MsgType=&) which successfully passes de-encryption, > CheckSum and BodyLength checks. (As a rule, messages should be forwarded > to the trading application for business level rejections whenever > possible.) > > Rejected messages should be logged and the incoming sequence number > incremented. > > Regards, Greg. > > > Hello, > > > > I had the following problem and don’t really know how it should be > > handled: > > > > First I send an order which is rejected for any reason, for example > > “Unknown instrument”. My counterparty sends me an ExecutionReport with > > this information, but due to the unknown instrument the value in tag > > “Symbol” (55) is empty. On my side this leads to a Reject Message. > > > > So far so good. But: The ExecutionReport has been received, but not > > really handled, so I don’t increment the incoming SequenceNumber. Due > > to this, my application sends a ResendRequest and the whole game > > starts again… The result is a never-ending loop with ResendRequest - > > ExecutionReport - Reject - SequenceReset … > > > > In my opinion, the counterparty should react somehow to my Reject > > Message. Or at least doesn’t resend the faulty ExecutionReport. > > > > Does anybody had the same problem before or any ideas how I should > > solve this? > > > > The FIX 4.2 Specification tells only that “there should be some > > logic…” 😉 : > > > > “Note: The receiving application should disregard any message that is > > garbled, cannot be parsed or fails a data integrity check. Processing > > of the next valid FIX message will cause detection of a sequence gap > > and a Resend Request will be generated. Logic should be included in > > the FIX engine to recognize the possible infinite resend loop, which > > may be encountered in this situation.” > > > > Thanks for any help or ideas! Eva ---
**Author:** ![srithayaparan\_x](https://avatars.discourse-cdn.com/v4/letter/s/d9b06d/32.png) [@srithayaparan\_x](https://forum.fixtrading.org/u/srithayaparan_x)\ **Post date:** [June 25, 2008, 6:40am UTC](https://forum.fixtrading.org/t/rejection-loop/13128/5 "2008-06-25T06:40:38Z")
Eva, There are two types of protocol rejection in FIX and a business rejection as well. 1. Session level reject (Type 3 I think). 2. Business Reject (Type J) 3. Execution Report - Exec Type = 8 (Type 8) Now all these are rejects of one for or the other, but responding to these three is entirely different. Session Level Reject :- Any basic Session validation failure. It includes the following :- 1. Sequence errors 2. Required field missing errors 3. Tag not defined errors - For more info see session error codes\* ONLY THIS TYPE SHOULD NOT RESULT IN RECVD SEQ INCREMENT. In your case the reject you offer is probably a Business Reject. Its an app layer reject in Fix. This will probably require incrementing the internal recvd sequence number do that the next expected is one added to the erroneous message. Generally, in practice, a certified FIX Engine shouldn’t all of a sudden throw off session rejects in the midst of production. If so, something is seriously wrong and should be rectified perhaps manually. This is the practice we use. Rgds, Thaya. > Hello Greg, > > indeed I I have to Sequence Numbers in my system: SeqNum\_rcvd und > SeqNum\_done. Indeed the SeqNum\_rcvd will be incremented also in case of > rejection. But I’m not sure if I also shall increment the SeqNum\_done - > finally the message is not handled correctly. > > So in fact it’s the question how to react correctly. To loop is wrong, > sure. But is it more correct to just ignore and log the message that > couldn’t be handled? Maybe this leads to some other unexpected > effects… > > Or does it make sense to close the connection in this case with an > error? > > Maybe I’m overestimating this case but maybe it’s worth to discuss it a > little bit? > > Bye Eva > > > Eva, > > > > You should increment the next expected sequence number when rejecting > > an incoming message. You should not be sending the resend request in > > your scenario. > > > > From the FIX 4.0 & 4.2 specs: > > > > The reject message should be issued when a message is received which > > cannot be passed through to the application level. An example of when > > a reject may be appropriate would be the receipt of a message with > > invalid basic data (e.g. MsgType=&) which successfully passes de- > > encryption, CheckSum and BodyLength checks. (As a rule, messages > > should be forwarded to the trading application for business level > > rejections whenever possible.) > > > > Rejected messages should be logged and the incoming sequence number > > incremented. > > > > Regards, Greg. > > > > > Hello, > > > > > > I had the following problem and don’t really know how it should be > > > handled: > > > > > > First I send an order which is rejected for any reason, for example > > > “Unknown instrument”. My counterparty sends me an ExecutionReport > > > with this information, but due to the unknown instrument the value > > > in tag “Symbol” (55) is empty. On my side this leads to a Reject > > > Message. > > > > > > So far so good. But: The ExecutionReport has been received, but not > > > really handled, so I don’t increment the incoming SequenceNumber. > > > Due to this, my application sends a ResendRequest and the whole game > > > starts again… The result is a never-ending loop with ResendRequest > > > > > > - ExecutionReport - Reject - SequenceReset … > > > > > > In my opinion, the counterparty should react somehow to my Reject > > > Message. Or at least doesn’t resend the faulty ExecutionReport. > > > > > > Does anybody had the same problem before or any ideas how I should > > > solve this? > > > > > > The FIX 4.2 Specification tells only that “there should be some > > > logic…” 😉 : > > > > > > “Note: The receiving application should disregard any message that > > > is garbled, cannot be parsed or fails a data integrity check. > > > Processing of the next valid FIX message will cause detection of a > > > sequence gap and a Resend Request will be generated. Logic should be > > > included in the FIX engine to recognize the possible infinite resend > > > loop, which may be encountered in this situation.” > > > > > > Thanks for any help or ideas! Eva