-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auditing the position tracking in the execution engine #3364
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nonblocking: Is it possible to have a log object passed in at creation time for the positions type instead of passing it into the functions that use it?
It is possible, although I'm not sure we should store that in the MarketPosition which is pretty much a pod type. |
applyFees is called in SubmitOrder, orderCancelReplace and LeaveAuction. While it would be acceptable to unregister the order when in the 2 first ones, it is not when LeavingAuction as this is applied on orders already uncrossed for which the position has been updated previously in handleConfirmation. This the unregister order out of the applyFees function, and call it from the caller.
Not finding a position in this engine should never be possible, this would mean that we did not register a position properly, or that we are trying to unregister one which has maybe already been unregistered. In any case that's a bug, and shall never happen, a panic is appropriate in this case.
For both these calls the following applies, it should be impossible to: - update a position for a party which never registerer a potential positon - decrease a potential position for more than the actual potential position (basically assert trade.Size < potential{buy/sell}
…Order We know added the following check in cases we AmendOrder: - Panic if the party did not have a position - Panic if the Remaining from the original order is > potential{buy/sell} We know added the following check in cases we UnregisterOrder: - Panic if the Remaining from the original order is > potential{buy/sell}
f29bcde
to
f157b30
Compare
- ensure we insert the new expiry date when amending changes it - cancel orders before settings flags for expiry changes, (make \ sure we do not expire twice, or add non-existing orders) - ensure we do not reduce position for order not foundInTheBook - remove PeggedOrder from the list if it's been cancelled by amend
- use unregisterAndReject if error on book - use IsFinished in SubmitOrder - do not submit pegged order to the book if auction is started
This will add a couple of things:
I'll try to keep the commit message sensible, please review eventually them one by one.