WebSocket data stream stops after some time

[feldblick]

Question: WebSocket Data Stream Stops After ~20 Minutes (Connection Remains Healthy)

Summary

I'm experiencing an issue where the WebSocket data stream stops sending messages after approximately 20 minutes, even though the connection remains healthy (OPEN state, ping/pong working perfectly). I'd like to understand if this is expected behavior or if I'm missing something in my implementation.

Environment

• Node.js Version: v22.14.0
• Official Client: @polymarket/real-time-data-client v1.4.2
• Libraries: ws v8.18.0, isomorphic-ws v5.0.0
• Operating System: Windows 11
• Server: wss://ws-live-data.polymarket.com

Observed Behavior

When subscribing to the activity feed, the connection exhibits this pattern:

1. ✅ Initial Connection: Works perfectly, receives messages at ~14-30 msg/sec
2. ✅ Ping/Pong: 99.6% success rate throughout entire session
3. ❌ Data Stream: Stops after ~20 minutes (no more messages)
4. ✅ Connection State: Remains OPEN, no error/close events
5. ✅ Ping/Pong: Continues working after data stops

Test Results

Test Duration: 37.5 minutes
Messages Received: 31,754 messages
Last Message Time: 09:48:24 (21 minutes into test)
Connection Closed: Never (still OPEN at end of test)

Ping/Pong Statistics:

Total Pings Sent:      448
Total Pongs Received:  448
Success Rate:          99.6%
Last Ping:             0.1s ago (still working at 37.5 minutes)
Last Pong:             0.1s ago (still working at 37.5 minutes)

Data Stream Statistics:

Last Data Message:     1,295 seconds ago (21+ minutes)
Connection State:      OPEN
Error Events:          0
Close Events:          0
Freeze Warnings:       42 consecutive

Test Code

Using the official RealTimeDataClient with minimal configuration:

import { RealTimeDataClient } from '@polymarket/real-time-data-client';

const client = new RealTimeDataClient({
    onConnect: (client) => {
        console.log('Connected!');
        client.subscribe({
            subscriptions: [{
                topic: "activity",
                type: "*",
                filters: ""
            }]
        });
    },
    onMessage: (client, message) => {
        // Just count messages - no processing
        messageCount++;
    },
    onStatusChange: (status) => {
        console.log('Status:', status);
    },
    autoReconnect: false  // Disabled to observe behavior
});

client.connect();

My Questions

1. Is this expected behavior? Should WebSocket connections be treated as short-lived (< 20 minutes)?

2. Rate limiting or connection policy? Is there a server-side policy that stops sending data after a certain duration or message count?

3. Recommended reconnection strategy? Should clients reconnect proactively every X minutes for long-running applications?

4. Why no close/error event? If the server wants to stop the connection, should it send a close frame instead of just stopping data?

5. Data timeout detection? Should the client library implement timeout monitoring for data messages (separate from ping/pong)?

6. Production recommendations? What's the recommended approach for 24/7 production applications (trading bots, monitoring, etc.)?

What I've Tried

• ✅ Minimal processing: Test code only counts messages, no async operations
• ✅ Different subscriptions: Tried trades-only and all activity types
• ✅ TCP optimization: setNoDelay, setKeepAlive - no effect
• ✅ Different libraries: Tested both ws and isomorphic-ws
• ✅ Verified ping/pong: Confirmed WebSocket ping/pong mechanism works perfectly

Current Workaround

I've implemented a data message timeout monitor:

const DATA_TIMEOUT_MS = 5 * 60 * 1000; // 5 minutes
let lastDataMessageTime = Date.now();

setInterval(() => {
    const timeSinceLastData = Date.now() - lastDataMessageTime;
    if (timeSinceLastData > DATA_TIMEOUT_MS) {
        console.warn('No data for 5 minutes - reconnecting');
        client.disconnect();
        client.connect();
    }
}, 30000);

This works, but I'd prefer to understand the root cause.

Additional Context

• Issue is reproducible across multiple test runs
• Occurs at different times of day
• Occurs regardless of market activity level
• Time to freeze varies slightly (18-22 minutes typically)
• Ping/pong proves the TCP/WebSocket connection is healthy
• No correlation with specific message types or content

Request

Could you help me understand:

• Whether this is expected server behavior?
• If there are documented best practices for long-running connections?
• Whether the official client should include data timeout monitoring?

I'm happy to provide more diagnostic information or test different configurations. Thank you for maintaining this library and for any guidance you can provide!

Reproduction

Full test code and logs available upon request. The issue is consistent and reproducible with the minimal example shown above.

[feldblick]

@poly-rodr

[feldblick]

#25 (comment)

Thanks @nopsled for reproducing the issue. Let's continue here with the conversation.

I also have some thoughts about workarounds but would be nice to know what's going on in the background/server side of the websocket.

[nopsled]

The issue is possible not related to this package but the endpoint and backend. If you try to communicate with the endpoint itself not using the package you end up having the same issue of datastream "freezing".

[mukul013]

Hey @feldblick
Is this issue still persist or did you find any fix for it ?

[feldblick]

Still present. My fix is currently to open a backup websocket and switch to that one when the main one freezes.

[mukul013]

Still present. My fix is currently to open a backup websocket and switch to that one when the main one freezes.

Nice, can you provide a gist for that?
It would save me some time. Thanks!

[feldblick]

Still present. My fix is currently to open a backup websocket and switch to that one when the main one freezes.

Nice, can you provide a gist for that?
It would save me some time. Thanks!

Unfortunately I directly implemented it in my own product, not into this client. And I must say that I have not finished testing yet.

[JusSchw]

Im experiencing the same issue

[jchook]

@feldblick thank you very kindly for all of your investigation into this issue.

Using this official package, I also see the issue.

I see data flowing steadily for some minutes, then it suddenly stops for some minutes, then continues again. I do not see any onError events when this happens, also I have confirmed that this is not due to market duration boundaries.

[GorillaDaddy]

Huge problem. Can confirm. Also the sockets aren't receiving continuous updates. Nothing for 10s, then a burst. Are there more endpoints?

[jchook]

The Clob WSS API is much more reliable and information-dense.

However, unlike RTDS, the WSS API does not provide proxyWallet information on other user's trades.

[Tarryco]

Two months have passed, have you found the perfect solution yet?

[jchook]

@Tarryco looks like they quietly discontinued support for most of this data, only supporting comments and crypto prices.