Yes — your reading is correct. Each slice is placed as a separate order with its own order_id, and Kite stamps the autoslice tag plus an autoslice: tag on the slices (staff have confirmed this in the earlier autoslice threads). So your own tag can't be the per-order deterministic key across slices — even if it rides along on each child, it's identical on all of them, so it won't uniquely identify a slice. The key that is stable is the parent order_id returned in the place_autoslice_order response (alongside the children list). Reconcile against that:
At placement, store your business correlation in a side map keyed by the parent order_id. Group child fills back to the parent via their autoslice: tag. Treat your own tag as metadata attached to the parent, not as the join key.
So: parent order_id = correlation ID, your tag = metadata. Keeps reconciliation deterministic without depending on a tag field Kite co-owns. (If you'd rather size slices yourself, note there's no public endpoint for per-instrument freeze quantities — you'd maintain those from the exchange files.) Reference build with that parent→children reconciliation pass: github.com/Finance-broski/kite-execution-pipeline — happy to answer setup questions.
Good question — this is the scenario that actually matters in production. Short answer: the order isn't lost, only the response is. The slice was accepted the moment it hit the broker; a dropped connection just means you didn't receive the order_id back. So the trick is to not depend on that response surviving. To be precise about how the repo handles it (I've just hardened it for exactly this): it slices client-side and assigns each slice a unique, deterministic tag that's journaled to disk before the order goes out. That gives you two keys:
order_id — the fast in-session join key. tag — the crash-recovery key. Because you assigned it yourself, pre-placement, it survives even when the response doesn't.
On reconnect you re-fetch kite.orders() and match on your tag to recover the order_id + status of anything whose response you lost. And after a timeout you reconcile-then-decide, never blind-retry — if the tag's already in the book, the slice is live, so you don't re-place it. That's how you avoid duplicate slices, which is the real risk in this scenario. I slice client-side rather than lean on the broker's slice response precisely for this reason — you own the tag, so you're never dependent on a packet you might not receive. The per-slice tag + pre-placement journal live in kite_orders.py, and the tag-fallback recovery in kite_reconcile.py (with tests for the lost-response case): https://github.com/Finance-broski/kite-execution-pipeline
The docs promise that an optional, user provided Tag is used for identifying the order. When you mutate this when auto slicing is applied, you are breaking this promise.
While the auto slice feature is very useful and alleviates the need for maintaining the underlying wise freeze limits at our end, your mutating the Tag makes it unusable for most of the folks.
Please retain the user provided Tag at least for the parent order so that the auto slice feature becomes usable.
@FinanceBroski Yes, I'm aware of those constraints and have been doing the slicing at my end. My question is more rhetorical and aimed towards pointing out the obvious. Apologies for not being more specific. (You've got a nice repo there, btw.)
The key that is stable is the parent order_id returned in the place_autoslice_order response (alongside the children list). Reconcile against that:
At placement, store your business correlation in a side map keyed by the parent order_id.
Group child fills back to the parent via their autoslice: tag.
Treat your own tag as metadata attached to the parent, not as the join key.
So: parent order_id = correlation ID, your tag = metadata. Keeps reconciliation deterministic without depending on a tag field Kite co-owns. (If you'd rather size slices yourself, note there's no public endpoint for per-instrument freeze quantities — you'd maintain those from the exchange files.)
Reference build with that parent→children reconciliation pass: github.com/Finance-broski/kite-execution-pipeline — happy to answer setup questions.
So the trick is to not depend on that response surviving. To be precise about how the repo handles it (I've just hardened it for exactly this): it slices client-side and assigns each slice a unique, deterministic tag that's journaled to disk before the order goes out. That gives you two keys:
order_id — the fast in-session join key.
tag — the crash-recovery key. Because you assigned it yourself, pre-placement, it survives even when the response doesn't.
On reconnect you re-fetch kite.orders() and match on your tag to recover the order_id + status of anything whose response you lost. And after a timeout you reconcile-then-decide, never blind-retry — if the tag's already in the book, the slice is live, so you don't re-place it. That's how you avoid duplicate slices, which is the real risk in this scenario.
I slice client-side rather than lean on the broker's slice response precisely for this reason — you own the tag, so you're never dependent on a packet you might not receive. The per-slice tag + pre-placement journal live in kite_orders.py, and the tag-fallback recovery in kite_reconcile.py (with tests for the lost-response case):
https://github.com/Finance-broski/kite-execution-pipeline
Dear Kite Team,
The docs promise that an optional, user provided
Tagis used for identifying the order. When you mutate this when auto slicing is applied, you are breaking this promise.While the auto slice feature is very useful and alleviates the need for maintaining the underlying wise freeze limits at our end, your mutating the Tag makes it unusable for most of the folks.
Please retain the user provided
Tagat least for the parent order so that the auto slice feature becomes usable.@FinanceBroski Yes, I'm aware of those constraints and have been doing the slicing at my end. My question is more rhetorical and aimed towards pointing out the obvious. Apologies for not being more specific.
(You've got a nice repo there, btw.)
tagsappear to be getting updated correctly in the sliced orders reflected in the orderbook.