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
Futures WebSocket: Multiple stream types return successful SUBSCRIBE ACK but send zero data frames #526
Several Futures WebSocket stream types accept subscriptions and return {"result":null,"id":99} (successful ACK) but never send any data frames. This has been ongoing for approximately 6 hours as of this report.
Affected streams (zero data after successful subscribe):
async def test():
async with websockets.connect("wss://fstream.binance.com/ws") as ws:
# This stream works:
await ws.send(json.dumps({"method": "SUBSCRIBE", "params": ["btcusdt@trade"], "id": 1}))
print(await asyncio.wait_for(ws.recv(), timeout=5)) # ACK
print(await asyncio.wait_for(ws.recv(), timeout=5)) # Data frame received
# This stream does NOT work:
await ws.send(json.dumps({"method": "SUBSCRIBE", "params": ["btcusdt@aggTrade"], "id": 2}))
print(await asyncio.wait_for(ws.recv(), timeout=5)) # ACK received
print(await asyncio.wait_for(ws.recv(), timeout=10)) # TimeoutError — no data
asyncio.run(test())
Environment:
Endpoint: wss://fstream.binance.com/ws
Location: Tokyo (Vultr VPS)
Tested via URL-based (/ws/), combined (/stream?streams=...), and method-based SUBSCRIBE — all behave identically
websockets Python library, but the issue is server-side — the connection and subscription succeed, the server simply never sends data frames for the affected stream types
Impact: Any application relying on aggTrade, kline, markPrice, or forceOrder streams via Futures WebSocket is silently receiving no data despite successful subscription. There is no error message or disconnect — the connection remains alive, making this difficult to detect without explicit data-frame-level monitoring.
Notes:
The @trade stream (non-aggregated) works for the same symbols where @aggTrade does not
The @depth20 stream works normally
This appears to be a server-side regression, not a client issue
Update: The outage has expanded. In addition to the originally reported aggTrade and forceOrder streams, kline_1m and markPrice@1s are now also affected. These streams were initially working on pre-existing connections, but after those connections expired (24h lifetime), new subscriptions exhibit the same behavior — successful ACK, zero data frames.
Current state (~14 hours into the incident):
DEAD (ACK but zero data): aggTrade, kline_1m, markPrice@1s, forceOrder
ALIVE: depth20@500ms, trade
4 of 6 Futures WebSocket stream types are now non-functional despite successful subscriptions. Only depth20 and trade continue to deliver data.
Activity
uibeka commentedon Apr 24, 2026
Update: The outage has expanded. In addition to the originally reported aggTrade and forceOrder streams, kline_1m and markPrice@1s are now also affected. These streams were initially working on pre-existing connections, but after those connections expired (24h lifetime), new subscriptions exhibit the same behavior — successful ACK, zero data frames.
Current state (~14 hours into the incident):
DEAD (ACK but zero data): aggTrade, kline_1m, markPrice@1s, forceOrder
ALIVE: depth20@500ms, trade
4 of 6 Futures WebSocket stream types are now non-functional despite successful subscriptions. Only depth20 and trade continue to deliver data.
alplabin commentedon Apr 27, 2026
Hey @uibeka, Have you seen that new entry points have been added to call these endpoints?
If you want to retrieve WebSocket data using this library, we suggest looking at the example provided or testing it using the following code:
feat(common): add optional WebSocket-Streams lifecycle callbacks
feat(common): add optional WebSocket-Streams lifecycle callbacks