If I rephrase it for sake of my understanding:
In your experience, some request and at least reqPnL does act as an "On" switch about what is send back as "id" when an error is reported.
When this condition is triggered (trough for example a first successful? reqPnL) then any request like reqOrder that failed will report it's reqId instead of the Orderid.
Of course this impact only request that use an orderid, but allegedly impact every of them.
Right ?
What language are you using ?
Which version of the API ?
Are you connected as ClientID 0 ?
Speculation that come to my mind are:
1- This may happen on errors generated before IB server is even able to interpret the order ID in message sent. (this kind of error may contains the wording "....Java Parsing Error ....")
Then IB report what is the next easiest id at hand, which is the reqid.
If you use C++ with API > rev 10.XX I can imagine a reasons related to the way Decimal is used for quantity. (tough It's difficult to match your case and I don't see the link with reqPnL as a trigger)
2- You may be re-using an orderid of an already pending orderid (or use 0 ), then IB doesn't know what is the consistency of an error report that refer this orderId, as it was legit in the past, and IB then fall back on reqid. Never tried the case. So speculation here.
Farfetched but ...
It might be good to know more about a faulty 'Order oriented' request.
Which reqXXX failed , what are it's object content ? (What was the orderid and reqid ?)
What is the exact and full error message ?
If you make a reqAllOrders, are you sure your orderid is not in the reported orderid from openOrder call back ?
Does it happens on every subsequent order oriented request that error-ed ? or random and in an unpredictable manner ?
