[TexasCoding]

Closes #247

Part of #273 (post-v2.4 audit), Wave 0 docs patch.

[claude]

Code Review — PR #275

docs(orders): fix batch_create/batch_cancel examples for v2.4 typed responses

---

Overview

Docs-only patch to docs/resources/orders.md that updates batch_create and batch_cancel code examples to match the v2.4 typed response envelopes (BatchCreateOrdersResponse / BatchCancelOrdersResponse). The old examples iterated over what was previously a bare list[Order]; the new ones correctly walk result.orders, inspect entry.error, and access the right fields per entry.

Verified the examples against the actual model definitions in kalshi/models/orders.py.

---

Correctness

Both examples are accurate against the current models:

batch_create entry (BatchCreateOrdersResponseEntry):

• order: Order | None ✓
• error: dict[str, object] | None ✓
• client_order_id: str | None ✓ (may be None — printing it that way is fine)

batch_cancel entry (BatchCancelOrdersResponseEntry):

• order_id: str (required, always present) ✓
• reduced_by_fp: FixedPointCount ✓
• error: dict[str, object] | None ✓

---

Minor Issues

1. Implicit entry.order non-null assumption in the success branch (batch_create example)

else:
    print(entry.order.order_id, entry.order.status)

order is typed Order | None, so a type checker will flag this. The spec guarantees a successful leg always has a populated order, but that guarantee isn't reflected in the type. Consider guarding or adding an inline comment:

else:
    assert entry.order is not None  # spec: successful leg always has order
    print(entry.order.order_id, entry.order.status)

or at minimum add a comment so readers know why this is safe.

2. result unused in the final explicit-routing example

result = client.orders.batch_cancel([
    BatchCancelOrdersRequestOrder(order_id="ord_abc", subaccount=0),
    BatchCancelOrdersRequestOrder(order_id="ord_def", subaccount=1),
])

result is now assigned but never iterated. Either add a brief comment (# handle result as in the example above) or drop the assignment back to a bare call. The context makes the intent clear, but a first-time reader might wonder why the result is discarded.

---

Verdict

Both changes are correct and necessary — the old examples would have raised AttributeError on any v2.4+ install. The two issues above are cosmetic/robustness nits, not blockers.

Approve with nits. Either address the entry.order guard or add a spec-explains-this comment in the batch_create success branch; the unused result in the last block is the lower-priority of the two.