Anyone having an issue where you cancel an order, then call get orders, and the order still shows up there?
Anyone having an issue where you cancel an order, then call get orders, and the order still shows up there?
2026-06-21 · Kalshi · 7 条相关讨论
Anyone having an issue where you cancel an order, then call get orders, and the order still shows up there?
Anyone having an issue where you cancel an order, then call get orders, and the order still shows up there?
Happens sometimes*
Happens sometimes*
Wait so what's the recommended approach in this case?
Wait so what's the recommended approach in this case?
Cancel an order, then call `Get User Data Timestamp`, add a delay if ts is before current ts, then call `Get Orders`?
Cancel an order, then call `Get User Data Timestamp`, add a delay if ts is before current ts, then call `Get Orders`?
i'm not sure there is a recommended way. what i do is read my orders once at startup after possibly sleeping until user_data_timestamp is settled, and thereafter maintain my own local view of what orders i currently think i have resting, and update it from websocket data and my own order placement/cancellation. i've found that user_data_timestamp is reliable enough for this. if you really need to rely on getorders instead of keeping local state, yeah, you'll be sleeping a lot
i'm not sure there is a recommended way. what i do is read my orders once at startup after possibly sleeping until user_data_timestamp is settled, and thereafter maintain my own local view of what orders i currently think i have resting, and update it from websocket data and my own order placement/cancellation. i've found that user_data_timestamp is reliable enough for this. if you really need to rely on getorders instead of keeping local state, yeah, you'll be sleeping a lot
(and by "settled" i mean roughly:) ``` start = now() while get_user_data_timestamp() < start: sleep ```
(and by "settled" i mean roughly:) ``` start = now() while get_user_data_timestamp() < start: sleep ```
It's a bug
It's a bug