Polymarket: new orders remain transmissible after order-safety heartbeat failure #5021
Unanswered
investlink-ai
asked this question in
Q&A
Replies: 1 comment
|
Thanks—that distinction is helpful. I propose rejecting new submissions
once heartbeat health is declared unhealthy, rather than
queuing potentially stale orders, and reopening admission only after
reconnect and a fresh heartbeat acknowledgement. Cancel and
query operations would remain available, and the existing heartbeat
failure thresholds would remain unchanged.
I have a locally tested native-adapter patch covering single/batch
submissions, modifications, rate-limit waits, and reconnect. With
the locally rebuilt wheel, the loopback Strategy.submit_order
reproduction produces OrderDenied and zero create-order requests after
the heartbeat 401.
Separate adapter tests cover already-accepted orders and requests racing
with heartbeat loss. These remain exposure until
authoritative order events or reconciliation establish their outcome;
heartbeat loss alone does not mark them canceled. The tests use
mocks and do not verify Polymarket’s live cancellation timeout.
Would maintainers support a focused PR implementing and documenting these
semantics, and would you prefer a tracking issue first? If
someone is already working on this, I’m happy to coordinate and share the
patch and regression tests.
Regards,
Sam
…On Mon, 21 Sept 2026 at 03:06, Erol Tasci ***@***.***> wrote:
I would treat this as a fail-closed safety boundary, and your reproduction
exposes a gap between heartbeat health and order admission. In the documented
contract at the commit you linked
<https://github.com/nautechsystems/nautilus_trader/blob/b2f61748ba90dd0adb8e5b9918ce56ddc97970eb/docs/integrations/polymarket.md>,
a missed heartbeat leads Polymarket to cancel open orders after its
timeout, while the adapter reports disconnected after heartbeat failures
and asks the operator to reconnect. I do not see a documented guarantee
that submit_order is locally rejected during that disconnected interval,
so the behavior you observed is consistent with the current wording.
For an order-safety heartbeat, I would expect new submissions to be
rejected or held until a heartbeat is acknowledged again. The venue timeout
is still important for orders already accepted by the venue; a local gate
cannot replace that cancellation contract. It would help to make the
intended behavior explicit for both new submissions and orders racing with
a heartbeat failure.
A focused regression test could acknowledge the initial heartbeat, force a
retryable failure or auth rejection, call Strategy.submit_order, and
assert that no create-order request is sent until reconnect and heartbeat
acknowledgement. A separate assertion should cover the fate of an order
that was already open at the venue.
—
Reply to this email directly, view it on GitHub
<#5021?email_source=notifications&email_token=B6FVOINP2GVJYJ4IWKWZUV35QAFAZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGI4TMNBUUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18529644>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/B6FVOIIMK2PYV2XZPMIERPL5QAFAZAVCNFSNUABIKJSXA33TNF2G64TZHMYTGOBVGUZDCOJWHNCGS43DOVZXG2LPNY5TCMBYGQYTOMRZUF3AE>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/B6FVOIIHTXXZNM6APCISNGT5QAFAZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGI4TMNBUUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM>
and Android
<https://github.com/notifications/mobile/android/B6FVOIJE7WVWVNO2LUJJOBT5QAFAZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGI4TMNBUUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>.
Download it today!
You are receiving this because you authored the thread.Message ID:
<nautechsystems/nautilus_trader/repo-discussions/5021/comments/18529644@
github.com>
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
With the official Polymarket execution adapter and
heartbeat_enabled=True, a neworder still reaches a loopback HTTP server after NT logs a heartbeat authentication
failure. I reproduced this on
2.0.0rc5and2.0.0rc6.dev20260916using nativefactories and
Strategy.submit_order, without custom execution-client code.I am opening a Discussion to clarify the intended contract. The
order-safety heartbeat documentation
describes disconnected health reporting after a failure; I did not find an explicit
guarantee that subsequent submissions are blocked locally.
Should the adapter reject new submissions while heartbeat health is lost, or is
that the caller's responsibility? If it belongs to the caller, what public Python
API or notification should a native-factory strategy use to enforce that policy?
Reproduction
The self-contained script below starts a synthetic HTTP/WebSocket venue on
127.0.0.1, supplies dummy credentials and uses the official factories. It:/v1/heartbeatsrequest.Polymarket heartbeat authentication failedlog.POST /order.The parent process observes the native log and signals the child through stdin;
submission is not scheduled using a fixed sleep after the server's response.
max_retries=0and execution reconciliation is disabled to isolate the path.Save the script below as
reproduce.pyand run from outside an NT source checkout:To repeat with the development wheel in a separate environment:
Observed results
Tested on 2026-09-18, macOS 26.6.2 ARM64, CPython 3.12.11, aiohttp 3.13.3.
2.0.0rc5, PyPI2.0.0rc6.dev20260916, official package indexBoth healthy controls exit 0. Both
--assert-blockedruns exit 1 because theproposed no-transmission assertion fails. The failure sequence is:
The mock intentionally accepts
/order; this demonstrates local transmission andthe resulting NT lifecycle, not actual Polymarket acceptance or financial loss.
The script does not directly read the Rust health flag. The inspected source logs
the authentication failure immediately before storing
false, so the stateinterpretation is source-derived; the runtime observation is after the log.
The development wheel was the latest compatible version returned by a refreshed
index query on this environment. I did not build or execute today's
develophead.Relevant source and scope
Source inspection at
developcommitb2f61748ba90dd0adb8e5b9918ce56ddc97970eb:logs the error, marks heartbeat health false and returns.
is_connected()includes heartbeat health when enabled.
submit_order_commanddispatches without checking that health state at this entry point.
This report covers a new single order after heartbeat authentication failure.
Batches, replacements, queued requests, retries, reconnects and already-in-flight
orders have not been exercised by this reproducer. A proposed adapter guard would
need explicit semantics for those cases while preserving cancellation and
reconciliation. No patch is included.
I searched the existing Polymarket heartbeat issues and PRs. The nearby
#4864 concerns market
WebSocket PING before subscription, which is different from this authenticated
order-safety heartbeat path.
Complete standalone reproducer (reproduce.py)
All reactions