Shared-storage topics are never freed: streaming leaks ~32 frames per page load
維護者通常 2 天內回覆
@T4rk1n 已經在處理了。
開始於 2026年9月24日。
評估
這個 Issue 還沒有評估資料。
描述
Describe the bug
Shared-storage pub/sub topics are never removed. The streaming transport (#3930/#3931) uses one topic per page load (stream_topic(connection_id) in dash/_stream_hub.py), and each topic keeps its last buffer_size (default 32) frames. So every page load that runs a streaming callback leaves its last 32 frames in memory for the life of the process.
With LocalSharedStorage, StoreEngine._topics (dash/_shared_storage/_engine.py) is a plain dict. _topic() adds an entry on first publish, head_seq or poll, and nothing ever deletes one. Pub/sub is not persisted, so the only thing that frees them is the owner process exiting.
Measured
A streaming callback yielding 40 frames of ~50 KB, driven headless with dash_duo: 20 page loads, then the browser navigates away and we wait 40s (past DOWNLINK_GRACE and POLL_GRACE).
- 20
_dash_stream:topics still inengine._topics - 640 frames still buffered (32 per topic)
- heap grew 39.9 MB, about 2 MB per page load
A long-running app streaming figures or LLM output grows without bound.
Other backends
DiskcacheSharedStorage:ss:seq:<topic>/ss:msg:<topic>:<n>are written withoutexpire. Bounded only by the cachesize_limiteviction.RedisSharedStorage: the seq counter and stream keys have no TTL.MAXLENlimits messages per topic, not the number of topics.
App code using ctx.shared_storage.publish/subscribe with per-session or per-run topic names leaks the same way (about 2.4 KB per empty topic on the local engine).
Expected behavior
A topic nobody uses any more is released. Some options:
- Local engine: drop a topic once it has no subscribers or waiters and has been idle past some window.
- Add
delete_topic(topic)toBaseSharedStorageand call it when aDownlinkconnection is finished (the pump already knows when the browser is gone). - A topic
ttl, matchingset(..., ttl=): RedisEXPIRE, diskcacheexpire=, a deadline in the local engine.
Streaming and shared storage are not released yet (4.5.0rc0), so this can be fixed before 4.5.0.
Repro
import asyncio
from dash import Dash, Input, Output, html
app = Dash(__name__)
app.layout = html.Div([html.Button("go", id="btn"), html.Div(id="out")])
@app.callback(Output("out", "children"), Input("btn", "n_clicks"),
prevent_initial_call=True)
async def cb(n):
for i in range(40):
await asyncio.sleep(0.01)
yield "x" * 50_000 + f"-{i}"
yield "done"
Load the page and click the button N times across reloads, then inspect app.shared_storage._coord.engine._topics: one _dash_stream:<connection_id> entry per page load, each holding 32 frames, long after the browser left.
- 主要語言
- Python
- 星號
- 24.4k
- 分支
- 2.3k
- 平均合併
- 1 天 20 小時
- 30 天內合併 PR
- 21
環境準備
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
plotly/dash 的其他 Issue
-
good first issue P3 size: 1 task
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 2 天內回覆
-
bug P2 plotly-internal size: 3
難度 4/5 3-5 天 新手友好度 48/100
維護者通常 2 天內回覆
-
bug P3 size: 1
難度 4/5 3-5 天 新手友好度 68/100
維護者通常 2 天內回覆
-
[BUG] disable autocomplete in the date pickers input可能已有人在做 @AnnMarieW 於 4 天前認領。 未關閉bug P2 size: 1
plotly/dash#4009 · 1 則留言 · 已指派 1 人 ·
維護者通常 2 天內回覆
-
[BUG] Plotly Cloud devtool route crashes with FastAPI and Quart backends可能已有人在做 @T4rk1n 於 4 天前認領。 未關閉bug P1 size: 1
難度 3/5 1-2 天 新手友好度 65/100
plotly/dash#4008 · 1 則留言 · 已指派 1 人 ·
維護者通常 2 天內回覆
相似的 Issue
-
[Bug] @deck.gl/arcgis dist import resolves to unpublished @deck.gl/core source path (9.3.11, 9.4.0)未關閉
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
workflow: a tick's dispatch counts as 'only this step', and no review self-grants a round unattended未關閉workflow
難度 2/5 1-3 小時 新手友好度 85/100
kristofdegrave/homeassistant-smart-charging#1505 ·
維護者通常 1 天內回覆
-
metadata submission
難度 2/5 1-3 小時 新手友好度 82/100
-
bug
難度 2/5 1-3 小時 新手友好度 65/100
canonical/content-cache-operator#163 · 1 則留言 ·
維護者通常 1 天內回覆
-
[submission]未關閉submission
難度 1/5 1 小時以內 新手友好度 65/100
leanprover/lean-eval-submissions#1852 ·
維護者通常 1 天內回覆