Please provide the supported recovery procedure for this situation using the Python Kite Connect SDK:
- A BUY has filled, creating an NFO index-option MIS position. - We submit a protective SL SELL with a unique tag. - The placement call times out or returns no usable order_id. - Subsequent authenticated order-book reads do not identify a matching order.
Acceptance is therefore unknown. Retrying could create a duplicate SELL, while waiting leaves the position potentially unprotected.
Please clarify:
1. How should we conclusively identify whether the original request was accepted? Which identifiers and endpoints should we use? 2. Is the order tag only an identification field, or does reusing it provide any server-side idempotency guarantee? 3. Is there a documented maximum visibility delay? Can absence from the order book ever conclusively establish nonacceptance? 4. Can an uncertain order be located or cancelled without its order_id, using a tag or another request identifier? 5. Which SDK exceptions or HTTP responses definitively guarantee that no order was created, and which must remain uncertain? 6. What supported procedure safely closes confirmed exposure without risking an unintended short position if the original SELL appears or fills later? Is a reduce-only or equivalent facility available for NFO options MIS?
Please include documentation links, recommended polling/backoff limits, and explicitly identify any guarantees the API does not provide.
We are asking for API behaviour and recovery guidance, rather than strategy coding assistance. A sanitised incident timeline can be supplied. Please advise a private channel if account-specific tracing is necessary.
