Client model graph grows on every plot-cell rebuild: two upstream BokehJS leaks

[SimonHeybrock]

Every rebuild of a plot cell leaves the previous cell's entire Bokeh figure subtree alive in the browser's model graph. The server-side document is cleaned up correctly; the client is never told to drop the models.

Measurement

Fake backend, committed dummy fixture, one browser session on the Detectors tab. Six stop/start cycles of dummy/area_panel_xy (each generation change replaces the plotter, bumps the layer version and rebuilds the cell), counting the client's model graph after each cycle via Bokeh.documents[0]._all_models:

cycle 0  total  594   Figures 4
cycle 1  total  733   Figures 5
cycle 2  total  872   Figures 6
cycle 3  total 1011   Figures 7
cycle 4  total 1150   Figures 8
cycle 5  total 1289   Figures 9

+139 models and +1 Figure per rebuild, monotonic. Expected steady state for that fixture is 4 figures (3 cells, one with two layers).

The same probe also shows stale stopped freshness pills lingering: after starting the jobs, the client still holds the 7 pill models from the pre-start widgets alongside the 3 new ones. A page reload leaves only the 3.

The server side is fine

PlotGrid._insert_widget_into_grid deletes the target region before assigning, and Panel's GridSpec._get_objects calls old._cleanup(root) for replaced children. Forcing doc.models.recompute() right after each _build_cell and reading len(doc.models._models), the server document does not grow by a cell subtree per rebuild — it creeps by roughly one model per stop/start cycle, which is a much smaller, separate question.

So the server knows the old models are unreachable and the client does not.

Why this matters beyond memory

A detached figure is not inert. The cell's HoloViews hooks are attached to the session's DynamicMap, which the stale figure still belongs to, so the stale figure keeps being rendered and keeps invoking those hooks. That is what broke the autoscale toolbar: CellAutoscaleController installed its CustomAction tools once per controller, and whichever figure rendered first consumed the installation, leaving the figure the user actually sees with an empty toolbar (flaky, and the reason autoscale toggles disappeared after tab switching). Fixed separately by keying installation on the toolbar, but the leak is the underlying cause and will keep producing this class of symptom.

It is also a plausible contributor to long-session slowdown: every job restart adds a full figure to the graph the client recomputes.

Not yet diagnosed

BokehJS's _all_models is reachability-based, so monotonic growth implies the removal never reached the client rather than the client failing to prune. Unverified hypothesis: a structural removal performed inside doc.models.freeze() does not emit the removal half of the PATCH-DOC. Both the poll pass and _BatchedTabs._update_active (plot_grid_tabs.py) wrap structural changes in pn.io.hold() + doc.models.freeze(). Confirming this means reading Bokeh's patch serialisation, and if it holds it is likely an upstream issue rather than ours.

Reproducing

.claude/rules/dashboard-widgets.md ("Driving the dashboard with Playwright") plus scripts/drive_dashboard.py cover the launch/drive setup. The driver clicks .lt-wf-area_panel_xy.lt-tool-player-stop / .lt-tool-player-play per cycle, returns to the Detectors tab, and evaluates the model count in the page.

Related: #1154 (freshness pill blank in an already-open session), found in the same code path.

[SimonHeybrock]

Root-caused: two separate upstream BokehJS bugs. Neither is in our code.

The hypothesis in the description is wrong: the removal does reach the client, and pn.io.hold() / doc.models.freeze() are not implicated. There are two independent upstream defects, and the one that matters for memory is not the one that produces the model count.

A — the client model graph never prunes (this is the reported symptom)

In bokehjs/src/lib/document/document.ts:

• apply_json_patch sets _hold_models_freeze = true, so no reachability recompute runs while a patch is applied. Container-property writes go through partially_update_all_models, which only ever adds refs to _all_models.
• Pruning therefore happens only in _recompute_all_models(), scheduled at the end of every apply_json_patch by _schedule_recompute_all_models().
• That scheduler is a trailing-edge debounce with recompute_timeout ?? 30_000 that cancels and reschedules on every call. Any app that patches more often than every 30 s never prunes at all.

Our poll tick patches every ~0.8 s. Measured over a full session: recomputes: 0 across 248 patches, max inter-patch gap 759 ms.

Proof that the removal arrives correctly — forcing the recompute once, by hand, after 6 stop/start cycles:

cycle 5           1305 models   9 Figures
forced recompute   271 models   3 Figures

Introduced in bokeh#14430 (milestone 3.7.1) as an explicitly temporary workaround for bokeh#14429 "Replacing Plot in a layout fails due to detached Document" — our exact scenario. Before that PR every container write recomputed the whole graph synchronously; the PR made the add half cheap (partially_update_all_models) and deferred the remove half, which then never runs. Still present on main. Every bokehjs unit test passes recompute_timeout: NaN to opt out of the debounce, so the 30 s default has no test coverage.

Not ours: 45 lines of plain Panel, no livedata code, neither hold nor freeze, reproduces it — +2 Figures per 6 s with recomputes: 0. Setting _recompute_timeout = 100 from the console holds it flat at 45 models / 1 Figure.

minimal reproducer

import time
import panel as pn
from bokeh.plotting import figure

pn.extension()
holder = pn.Column()
tick = pn.pane.Str("")

def rebuild():
    p = figure(width=300, height=200)
    p.line([1, 2, 3], [3, 1, 2])
    holder[:] = [p]

def poll():
    tick.object = f"tick {time.time():.1f}"

rebuild()
pn.state.add_periodic_callback(poll, period=1000)    # any periodic callback will do
pn.state.add_periodic_callback(rebuild, period=3000)
pn.Column(holder, tick).servable()

Then watch Bokeh.documents[0]._all_models.size in the console.

Fix, validated by monkeypatching it in-page: make it a throttle rather than a debounce — if (this._recompute_timer != null) return; instead of cancel-and-reschedule. Growth becomes a bounded sawtooth. With a 10 s window: shipped behaviour reaches 780 models / 22 Figures after 60 s, throttled returns to 45 / 1 on every window boundary.

B — pruning frees nothing (this is what actually costs memory)

Fixing A restores correct graph accounting and reclaims no memory: the models leave the graph but stay in the heap.

The retainer is not yet identified. Candidate mechanism, unverified: _recompute_all_models() calls only detach_document() on removed models, never destroy() / Signal.disconnect_receiver, so a signal connection held by a surviving sender would keep a whole removed subtree alive. Note this cannot simply be fixed by destroying removed models — with pn.Tabs(dynamic=True) a model legitimately leaves and re-enters the graph.

Measured with CDP Runtime.queryObjects (live instances of a prototype after two forced GCs), following the same forced prune as above:

                  in_graph   live_js
cycle 3                  7         7
forced recompute         3         7      <- dropped from the graph, still in the heap
+10s                     3         7

The same minimal Panel app: after a forced prune, in_graph=2 while live_js=14. So B is upstream too.

Byte cost: heap 21.8 → 31.4 MB over 6 stop/start cycles, ~1.5 MB per job restart. Control for the measurement — an idle streaming session holds flat at ~20 MB for 3 minutes, so that growth is retention, not stream data.

Corrections to the description

• "the stale figure keeps being rendered and keeps invoking those hooks" — not on the client. Across 3 cycles, Figure models went 3 → 6 while DOM canvases stayed at 8, root views at 13 and DOM nodes at 1865. The stale models have no views. HoloViews hooks are Python, so the client graph cannot drive them at all. Whatever broke the autoscale toolbar is a server-side retention (old pane/plot still subscribed to the session's DynamicMap), unrelated to this leak, and belongs in its own issue. Note cell_autoscale.py still gates installation on a plain self._tools_installed bool.
• "plausible contributor to long-session slowdown" — graph size is nearly free CPU-wise; _all_models is only used for O(1) id lookups during deserialization. The cost is memory, per B.
• Growth is episodic, not continuous. 2 minutes idle on the Detectors tab: flat at 471 models. Only structural rebuilds add. The 471 baseline is itself ~205 stale models accumulated during startup — one-time, and the same mechanism as the stale freshness pills noted above.

Next

• Both A and B go upstream; there is no existing bokeh issue for either.
• No local mitigation worth building. Forcing _recompute_all_models() from a hidden jscallback would fix the count and, per B, reclaim nothing. Dropping _recompute_timeout to 0 would restore a full graph recompute on every patch, which is the cost the debounce exists to avoid.