integration: order and status checks, no pending server messages #716
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This PR simply needs testing, and notes for breaking changes (API, db scheme, etc.). The individual commits have already gone through review. |
buck54321
reviewed
Oct 5, 2020
There was a problem hiding this comment.
Looks and tests well. Other than API used only internally, my quick tally of breaking changes is
IsRevokedfield fordb.MatchProofis now a method that returnsproof.ServerRevoked || proof.SelfRevoked. (actually, this one isn't used outside core probably)msgjson.OrderStatusResultrenamed toOrderStatusandFilledfield removed.msgjson.ConnectResultMatchesfield renamed toActiveMatches(jsonmatches->activematches).
Removes all server message caching, as well as the requirement to acknowledge match, audit, and redemption requests before progressing through match negotiation. This is intended to be the base upon which a match_status / order_status conflict resolution system is built.
* server/{auth,db}: connect response return active orders
(processes matches before order statuses)
* client/{core,db}: compare known order statuses against connect response
- Log error and issue notification for active orders reported by DEX that are
unknown to the client.
- Update order statuses where server-reported statuses are different from statuses
recorded by client.
- Set statuses to Executed, Canceled or Revoked for orders considered active by the
client but not returned by the DEX in the connect response. TODO: implement an
`order_status` route to accurately determine current statuses for such orders.
* simnet: add trading test for order status reconciliation
Also modify trade simnet test cases to run distinctly, wtih new clients
created for each test case, to prevent spillages across test cases.
* determine correct order statuses using order_status route
* retire stale cancel orders if target orders are still active
1. Match status resolution is run on startup and reconnects for any status mismatches observed when comparing the `connect` result with our local state. 2. Client will now begin negotiation based on the extra matches in the connect response. 3. Differentiate between server-initiated revocations and client-initiated revocations. Required a database upgrade. - Log error and issue notification for active orders reported by DEX that are unknown to the client. - Update order statuses where server-reported statuses are different from statuses recorded by client. - Set statuses to Executed, Canceled or Revoked for orders considered active by the client but not returned by the DEX in the connect response.
Before returning "only one cancel order can be submitted per order per epoch error" message, first check if the existing cancel order is stale and delete the cancel order to allow submission of new cancel order.
|
Thanks. Debugf fix rebased into the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This includes:
Matches status is processed before order statuses.
status-integPRs: #677, #699, #687, #704, #714Note: this PR will be merged via rebase, not squash so each of the commits are replayed on master.