Repository navigation
feat(finance): add a bounded retry policy for transient venue refusals - #6752
Merged
Merged
Conversation
A venue refuses an order for transient reasons (rate limits, request timeouts) and for terminal ones (insufficient balance, invalid precision). Retrying a submission is only safe when the executor first proves the earlier attempt produced no effect, so the decision helper takes that observation instead of assuming it. classify_venue_refusal() maps a bounded set of public refusal signals to retryable/terminal and treats anything unknown as terminal. RetryPolicy fixes the attempt budget, the backoff schedule and a wall-clock ceiling, and may_retry() returns a stable public token explaining the decision - visible effect, spent attempt or time budget, non-retryable refusal, or an operation deadline already reached. The module performs no IO, classifies no private material and grants no execution authority; venue adapters keep the actual submission and readback. Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
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.
Why
A venue refuses an order either transiently (rate limit, request timeout) or terminally (insufficient balance, invalid precision). Retrying is only safe when the executor has already proven that the previous attempt produced no effect — so the decision needs a policy that takes that observation rather than a bare loop. Every adapter otherwise re-implements this ad hoc, and the usual bugs are retrying terminal refusals or re-submitting after a delayed fill.
What
packages/loopx-finance-executiongainstransient_retry:classify_venue_refusal(message)→retryable/terminalover a fixed set of public signals (rate limit, request timeout, 稍后重试, try again). Unknown or empty text is terminal.RetryPolicy(max_attempts=4, waits_seconds=(12,25,35), max_total_seconds=150)validates its own bounds.may_retry(...)returns(allowed, reason)with stable tokens:venue_effect_observed,attempt_budget_spent,time_budget_spent,refusal_not_retryable,operation_expired,retry_admissible.next_wait_seconds(policy, attempt)gives the backoff, with the last entry repeating.Boundaries
Pure functions: no IO, no credentials, no venue call, no execution authority. The adapter still owns submission and the readback that feeds
venue_effect_observed.Verification
Covers rate-limit/timeout classification, terminal refusals, a visible effect blocking any retry, attempt and time budgets, the operation deadline, the backoff schedule and policy validation.