You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ConnectionManager.reconnect logs attempt failures at DEBUG with no exc_info — root cause lost #355
ConnectionManager.reconnect logs every failed attempt at DEBUG with no exc_info. When ws_max_retries (default 10) is exhausted the user sees only a generic KalshiConnectionError: Max reconnect attempts (10) exceeded with no __cause__ — the last exception was discarded by continue. Common failure modes (expired RSA key, revoked key ID, bad ws_base_url, TLS handshake error, DNS failure) are indistinguishable to the operator.
The REST transport's retry path surfaces the underlying exception by chaining via from. This WS path drops it. In production an operator looking at logs sees ten escalating-backoff warnings and a generic final error with no signal whether to rotate the key, escalate to Kalshi support, or check their NAT. The DEBUG attempt log is typically off in prod.
No exc_info=True, no last_exc captured, no raise ... from last_exc.
Suggested fix
Capture the latest exception and (a) log at warning with exc_info=True per attempt so an operator with the default log level sees what's going wrong, and (b) chain the final raise via from last_exc so the underlying failure stays on the traceback:
Activity
polish(ws): seq sync hot path + orphan correlation + reconnect exc_in…