fix(liquidity): recover Scrypt trade orders from transient WS errors#3879
Draft
TaprootFreak wants to merge 1 commit into
Draft
fix(liquidity): recover Scrypt trade orders from transient WS errors#3879TaprootFreak wants to merge 1 commit into
TaprootFreak wants to merge 1 commit into
Conversation
Scrypt sell/buy orders were marked as failed when the WebSocket connection dropped or timed out after the order was sent, losing the locally generated ClOrdID even though the exchange had executed the trade. - generate the ClOrdID in the adapter and persist it on the order before sending, so the trade stays verifiable - treat transient WS errors and request timeouts during placement and completion checks as recoverable: keep the order in progress and let the completion check resolve the actual state (lost orders still fail after the existing 60 min cutoff) - add a re-execution guard that checks for an existing trade by ClOrdID before placing a new order, preventing duplicate trades on retries - fetch all execution report pages in getOrderStatus instead of only the first page
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
When the Scrypt WebSocket connection drops or a request times out after a trade order (sell/buy) has been sent, the pending request is rejected and the liquidity management order is marked as
Failed. The locally generatedClOrdIDis lost (correlationIdstaysnull), even though Scrypt may have accepted and executed the order. The resulting trades are untracked, and the financial log counts the liquidity as pending indefinitely.Fix
ClOrdIDis generated in the adapter and saved on the order (correlationId) before the WS request goes out, so the trade stays verifiable in every failure mode.Connection closed,unknown reqid) and request timeouts during placement and completion checks no longer fail the order. The order transitions toInProgressand the existing completion check resolves the actual state via execution reports — filled orders complete with their output, orders that were never placed still fail after the existing 60 min cutoff (now anchored onorder.updated, i.e. placement time).correlationId(retry after crash or recoverable error), the adapter first checks for an existing trade byClOrdIDbefore placing a new one — preventing duplicate trades. The guard runs before the price/balance checks, since an open order locks the balance.getOrderStatusnow fetches all execution report pages (fetchAll) instead of only the first page, which the guard and completion check depend on.Tests
New
scrypt.adapter.spec.tswith 12 cases: persist-before-send ordering, recoverable placement errors (connection closed + both timeout variants), recoverable completion-check errors, rejected/insufficient-funds passthrough, idempotent re-execution (guard hit, guard miss with ClOrdID chaining, recoverable guard failure with and without existingcorrelationId).Out of scope (follow-up)
The same pattern (ClOrdID/ClReqID generated without persistence before send) still exists in the withdrawal path and in the
checkTradecancel-restart/edit paths.