Errors: 408 and 504 do not map to KalshiTimeoutError #251

Summary

KalshiTimeoutError was introduced (#226) exactly to expose the "may have committed" semantic so callers can branch on it (e.g., query by client_order_id before retrying an order create). 408 Request Timeout from an intermediary or CDN, and 504 Gateway Timeout from upstream, carry that same semantic but route to generic KalshiError and KalshiServerError respectively. Callers writing except KalshiTimeoutError to handle the documented "reconcile via client_order_id" path silently miss the HTTP-status variant of the same condition.

Location

• kalshi/_base_client.py:73-121 — _map_error status dispatch
• kalshi/errors.py:69-74 — KalshiTimeoutError definition

Evidence

if status in (400, 422):  ... KalshiValidationError
if status in (401, 403): ... KalshiAuthError
if status == 404: ... KalshiNotFoundError
if status == 409: ... KalshiConflictError
if status == 429: ... KalshiRateLimitError
if status >= 500: ... KalshiServerError    # swallows 504
# 408 falls through to: return KalshiError(message=message, status_code=status)

Recommended fix

Add if status in (408, 504): return KalshiTimeoutError(message=message, status_code=status) before the 5xx catch-all. Keep KalshiServerError for the rest of 5xx. Add regression tests.

Severity & category

medium / consistency