Skip to content

fix(bracket): poll fill status before abandoning an undefined-state entry - #179

Merged
TexasCoding merged 1 commit into
TexasCoding:mainfrom
blurxy:fix/bracket-fill-status-poll
Oct 29, 2026
Merged

TexasCoding merged 1 commit into
TexasCoding:mainfrom
blurxy:fix/bracket-fill-status-poll

Conversation

@blurxy

@blurxy blurxy commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #98, as discussed there.

Problem

In place_bracket_order, when the fill wait returns but _check_order_fill_status still reports 0 filled (the "undefined state" branch), the code rechecks once after 1 s, then cancels the entry and raises failed to fill after recheck. The status endpoint can lag a real fill by a few seconds. When it does, the entry is filled but the stop and target legs are never placed, so the position has no protection.

Change

  • The single recheck becomes a bounded poll: up to 6 checks, 1 s apart.
  • A fill seen during the window sizes the protective legs to the filled quantity and the bracket attaches as usual.
  • An order still at 0 filled after the window is cancelled and raises, as before. The message now says how many rechecks ran.

Tests

Two added to tests/order_manager/test_bracket_orders.py:

  • test_bracket_undefined_state_lagging_fill_attaches_bracket: a fill that appears on the second poll attaches the bracket and the entry is never cancelled.
  • test_bracket_undefined_state_genuinely_unfilled_still_raises: an order that stays at 0 filled is cancelled and raises.

Both fail on main without the change. The bracket test file passes with it (34 passed). ruff check and ruff format --check are clean on both files.

We have run this logic in production on our 3.5.9 fork since July.

🤖 Generated with Claude Code

…ntry

When the fill wait returns but the order-status endpoint still reports 0
filled, place_bracket_order rechecked once after 1s, then cancelled the
entry and raised. The status can lag a real fill by a few seconds, so a
filled entry was left without its stop and target legs.

Poll up to 6 x 1s instead. A fill seen during the window sizes the
protective legs to the filled quantity and the bracket attaches; an order
still at 0 filled after the window is cancelled and raised, as before.

Tests: two added (a fill on a later recheck attaches the bracket and is
never cancelled; an order that never fills is cancelled and raises). Both
fail on main without the change; tests/order_manager/test_bracket_orders.py
34 passed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JNt1FrUdgq9YmgPfBeiSwm
@TexasCoding
TexasCoding merged commit b575a23 into TexasCoding:main Oct 29, 2026
7 checks passed
TexasCoding added a commit that referenced this pull request Oct 29, 2026
place_bracket_order polls fill status up to 6 times (1s apart) when the
fill wait returns with 0 filled, so a lagging fill still gets stop and
target legs.

Thanks @blurxy. Refs #179. Related to #98.
@TexasCoding

Copy link
Copy Markdown
Owner

Thanks @blurxy! Merged and released in v4.4.2, which is now on PyPI. #98 stays open until we get a stock >=4.3.2 confirmation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants