I'm seeing odd WebSocket disconnect behavior and wanted to check if it's expected.
I'm seeing odd WebSocket disconnect behavior and wanted to check if it's expected.
2026-07-18 · Kalshi · 16 条相关讨论
I'm seeing odd WebSocket disconnect behavior and wanted to check if it's expected.
I'm seeing odd WebSocket disconnect behavior and wanted to check if it's expected.
Connections run for hours, then close with a TCP EOF. Immediate reconnects work initially, but connection lifetimes progressively shrink (2h --> 5m --> 47s). The final reconnect failed with 401 header_timestamp_expired even though the auth timestamp was generated immediately before the request and matched my local clock.
Connections run for hours, then close with a TCP EOF. Immediate reconnects work initially, but connection lifetimes progressively shrink (2h --> 5m --> 47s). The final reconnect failed with 401 header_timestamp_expired even though the auth timestamp was generated immediately before the request and matched my local clock.
here's a timeline of events: 01:32:06 - Connected successfully 03:38:28 - Received EOF 03:38:28 - Immediately reconnected 03:43:25 - Received EOF 03:43:25 — Immediately reconnected 03:44:12 — Received EOF 03:44:12 — Immediately reconnected 03:44:12 — Received 401
here's a timeline of events: 01:32:06 - Connected successfully 03:38:28 - Received EOF 03:38:28 - Immediately reconnected 03:43:25 - Received EOF 03:43:25 — Immediately reconnected 03:44:12 — Received EOF 03:44:12 — Immediately reconnected 03:44:12 — Received 401
I would check a couple things: 1: Are you consuming messages fast enough? If not, you will create backpressure and be disconnected. 2: I never get a 401 header_timestamp_expired. The first thing I would check is that your local clock is synchronized with NTP. Many have found that they just do not have the right time on their client.
I would check a couple things: 1: Are you consuming messages fast enough? If not, you will create backpressure and be disconnected. 2: I never get a 401 header_timestamp_expired. The first thing I would check is that your local clock is synchronized with NTP. Many have found that they just do not have the right time on their client.
Not necessarily. If your clock gradually falls out of sync and then resyncs once every 15 minutes or so, you would have these kinds of problems. Are you using NTP?
Not necessarily. If your clock gradually falls out of sync and then resyncs once every 15 minutes or so, you would have these kinds of problems. Are you using NTP?
Checked my machine clock. Network Time is enabled, and sntp reports only +0.003867s offset from time.apple.com (~4ms). The KALSHI-ACCESS-TIMESTAMP in my logs also matches my local send timestamp within milliseconds, so local clock drift doesn't appear to be the issue.
Checked my machine clock. Network Time is enabled, and sntp reports only +0.003867s offset from time.apple.com (~4ms). The KALSHI-ACCESS-TIMESTAMP in my logs also matches my local send timestamp within milliseconds, so local clock drift doesn't appear to be the issue.
401 header_timestamp_expired may be because you are caching the signature?
401 header_timestamp_expired may be because you are caching the signature?
i've never received ANY ping frames from kalshi
i've never received ANY ping frames from kalshi
an interesting detail with the second problem, check out these timestamps: SENT 2026-07-17 03:44:12.861175512 GET /trade-api/ws/v2 HTTP/1.1 ... KALSHI-ACCESS-TIMESTAMP: 1784274252860 RECV 2026-07-17 03:44:12.937047554 HTTP/1.1 401 Unauthorized Date: Fri, 17 Jul 2026 08:00:28 GMT
an interesting detail with the second problem, check out these timestamps: SENT 2026-07-17 03:44:12.861175512 GET /trade-api/ws/v2 HTTP/1.1 ... KALSHI-ACCESS-TIMESTAMP: 1784274252860 RECV 2026-07-17 03:44:12.937047554 HTTP/1.1 401 Unauthorized Date: Fri, 17 Jul 2026 08:00:28 GMT
when i run it on the unfiltered ticker subscription i avg 550 messages a second, and i'm running that for the same amount of time i'm running lifecycle subscriptions. like i said before, lifecycle is only running 15 messages a second. there's just no way its because i'm not consuming fast enough
when i run it on the unfiltered ticker subscription i avg 550 messages a second, and i'm running that for the same amount of time i'm running lifecycle subscriptions. like i said before, lifecycle is only running 15 messages a second. there's just no way its because i'm not consuming fast enough
I would think so, but I have had two kinds of self-inflicted disconnects: 1: When I am not consuming fast enough, I get unsubscribed from an individual channel. 2: Sometimes I just get a WebSocket closed event and lose the whole connection. I don't know why there are two different failure modes, but lately, if I am getting a WS disconnect more than once every other day, it is my fault. There have been problems on Kalshi's end before, but I think they are doing great lately.
I would think so, but I have had two kinds of self-inflicted disconnects: 1: When I am not consuming fast enough, I get unsubscribed from an individual channel. 2: Sometimes I just get a WebSocket closed event and lose the whole connection. I don't know why there are two different failure modes, but lately, if I am getting a WS disconnect more than once every other day, it is my fault. There have been problems on Kalshi's end before, but I think they are doing great lately.
i'm otherwise not interacting with kalshi, like literally all i'm doing is connecting and subscribing to lifecycle, with no pinging or anything after that. i don't send any other REST http requests either. do you think if i don't interact for a few hours they'd kick me off?
i'm otherwise not interacting with kalshi, like literally all i'm doing is connecting and subscribing to lifecycle, with no pinging or anything after that. i don't send any other REST http requests either. do you think if i don't interact for a few hours they'd kick me off?
Do you implement the keep-alive protocol? https://docs.kalshi.com/websockets/connection-keep-alive
Do you implement the keep-alive protocol? https://docs.kalshi.com/websockets/connection-keep-alive
My log shows that I get pings every 10-17 seconds.
My log shows that I get pings every 10-17 seconds.
Why did you write your own websocket client? Are the C++ libraries not good? I know that others use them, as <@1394462533946970274> mentions.
Why did you write your own websocket client? Are the C++ libraries not good? I know that others use them, as <@1394462533946970274> mentions.
have you tried using some off the shelf websocket implementation (maybe write a tiny python script using `websockets`) to see if the problem happens there too?
have you tried using some off the shelf websocket implementation (maybe write a tiny python script using `websockets`) to see if the problem happens there too?