[Polymarket] accepted order can remain ACCEPTED without fill or terminal event

[fedoraiver]

Summary

Some Polymarket orders receive OrderAccepted, but never emit OrderFilled or any terminal event. They remain in the Nautilus cache as residual ACCEPTED orders at shutdown.

This blocks strategies which rely on order lifecycle events to release risk limits or submit hedges.

Environment

• Adapter: Rust nautilus-polymarket
• Local nautilus_trader HEAD: c4700fabc018462f1305818f5d95e10010a0b37e
• Relevant commits included locally:
  • dd46ab0bed - Fix Polymarket ambiguous submit handling

Expected Behavior

After an order is accepted:

• If a venue trade exists, Nautilus should emit OrderFilled.
• If the venue order is terminal without a fill, Nautilus should emit the corresponding terminal status.
• The order should not remain indefinitely ACCEPTED after the venue-side lifecycle is complete.

Actual Behavior

Some orders receive OrderAccepted, account refreshes occur after finalized trades, but no fill or terminal event reaches the strategy. At shutdown, the orders remain residual ACCEPTED.

Evidence

In a live Polymarket run, multiple accepted orders were observed to remain in the local Nautilus cache without a corresponding fill or terminal order event.

The general sequence was:

1. Strategy submitted an order.
2. Nautilus emitted OrderAccepted.
3. Later account refreshes indicated finalized venue activity.
4. The strategy never received OrderFilled, OrderCanceled, OrderExpired, or terminal OrderRejected.
5. On shutdown, the cache reported residual orders still in ACCEPTED state.

This suggests the venue-side order lifecycle can progress while the local order cache remains unresolved.

Impact

Strategies see the lot/order as still pending because the cache remains ACCEPTED. With risk limits such as max_unlocked_lots=1, later entry and hedge opportunities are blocked even though the venue-side lifecycle appears to have progressed.

[cjdsellers]

Hi @fedoraiver,

Thanks for the careful writeup and the fix outline.

generate_order_status_report now falls back to /data/trades filtered by the venue order ID when /data/order/{id} is empty. With a cached order, the adapter surfaces Filled (dust-snapped) or Canceled with cancel_reason="ORDER_NOT_FOUND_AT_VENUE" so the engine resolves the local entry without dropping fills via the REJECTED path (both Python and Rust).

To drive this periodically rather than only on demand, set open_check_interval_secs on LiveExecEngineConfig. Details and a known partial-cancel-with-WS-loss limitation are under "Single-order recovery from trades" in docs/integrations/polymarket.md.

Let me know if anything still looks off in your live runs.