I am getting a new error code, `order_id_and_client_order_id_mismatch`, upon amend. Debugging now, but wondering if something changed.
I am getting a new error code, `order_id_and_client_order_id_mismatch`, upon amend. Debugging now, but wondering if something changed.
Ah! This looks like the old idempotence problem.
Ah! This looks like the old idempotence problem.
i almost never use my UI to manually trade except for testing purposes. 99% of it is performance displays that are customizable to sort various monitors and strategies for easy review or live trade monitoring (when I feel like doing that). I have custom settings for all of my strategies and monitors and the UI lets me tweak those without having to interact with the codebase or PG database tables directly. it would be a nightmare to stay on top of all of my various strats without a custom UI
i almost never use my UI to manually trade except for testing purposes. 99% of it is performance displays that are customizable to sort various monitors and strategies for easy review or live trade monitoring (when I feel like doing that). I have custom settings for all of my strategies and monitors and the UI lets me tweak those without having to interact with the codebase or PG database tables directly. it would be a nightmare to stay on top of all of my various strats without a custom UI
This seems to have something to do with the REST API being more flaky today and Amend Order not being idempotent. My system tries to amend an order, gets an error, retries the amend, and discovers that the amendment really did happen, despite the error.
This seems to have something to do with the REST API being more flaky today and Amend Order not being idempotent. My system tries to amend an order, gets an error, retries the amend, and discovers that the amendment really did happen, despite the error.
(Looks like my previous discussion of the idempotence problem has been deleted in Kalshi's new data retention process.)
(Looks like my previous discussion of the idempotence problem has been deleted in Kalshi's new data retention process.)
It seems like the only reason to have an optional client_order_id in the amend request would be to reject a no-match if the client uses that field. You're saying you're passing one, it reports no-match, but amends anyway?
It seems like the only reason to have an optional client_order_id in the amend request would be to reject a no-match if the client uses that field. You're saying you're passing one, it reports no-match, but amends anyway?
Yes, I am passing in the client_order_id. It is not yet clear to me why it is not matching. The first log indicated that I received an error on the amend, so I did not use the updated_client_order_id, but it seemed to be applied anyway.
Yes, I am passing in the client_order_id. It is not yet clear to me why it is not matching. The first log indicated that I received an error on the amend, so I did not use the updated_client_order_id, but it seemed to be applied anyway.
It looks like there just might be significant lag now between what Get Orders reports for client_order_id and what the exchange has. My system kept restarting and falling over until I took out the client_order_id that was not matching.
It looks like there just might be significant lag now between what Get Orders reports for client_order_id and what the exchange has. My system kept restarting and falling over until I took out the client_order_id that was not matching.
Cool. Now I am seeing a new error code, `order_ticker_mismatch`.
Cool. Now I am seeing a new error code, `order_ticker_mismatch`.
Yikes, sounds like this goes deeper.
Yikes, sounds like this goes deeper.
Yeah, and `order_side_mismatch`. Definitely could be a problem on my side, but I have no idea why the behavior has changed.
Yeah, and `order_side_mismatch`. Definitely could be a problem on my side, but I have no idea why the behavior has changed.