Purge per-kernel subscription residue at kernel close

[maartenbreddels]

TLDR

Kernel-scoped subscriptions on process-lifetime stores (module-level Reactive/Computed) were never removed at kernel close. Every kernel left (listener, Context) tuples — and everything the listener closures capture — behind, forever. A @solara.lab.computed inside a component body leaks its captures once per render. Found in a large production solara application leaking ~5 GB per instance per business day while every existing cleanup check stayed green.

Why nothing caught it

Effect-managed subscriptions unsubscribe at close (rc.close() runs effect cleanups), but Computed's AutoSubscribeContextManager subscribes outside any effect — and even module-level Computeds subscribe per kernel, since their value is kernel-scoped. The leaked entries do not pin the kernel context or render tree, so weakref assertions and kernels after close: 0 counters stay green. At lab scale the closures are KBs, hidden in the allocator tail; in production they captured MB-scale page data and pymalloc/glibc fragmentation amplified the scattered survivors ~7× at the OS level.

Full write-up: case study 4 in docs/memory-usage-inspection.md (added here), including the new detection rules and the amplification canary.

Design: the owner cleans up its own subscriptions

The subscriptions that leak all have an owner — the Computed's per-kernel AutoSubscribeContextManager, which already holds its unsubscribe closures. So:

• AutoSubscribeContextManager created inside a kernel registers kernel_context.on_close(self.unsubscribe_all). Kernel dies → its subscriptions are removed through the normal cleanup path. No external code mutates the listeners dicts, and session-scoped (persist=True) stores need no special casing: the owner removes exactly the entries it added.
• Unsubscribe cleanups prune empty scope entries, so unsubscribing leaves zero residue in the (defaultdict) listeners dicts.
• fire() no longer materializes defaultdict entries (previously: one permanent empty set per kernel that ever fired, per store).
• Singleton/Computed on_kernel_start registrations are unregistered when the creating kernel closes (Computed previously discarded the cleanup entirely). Registrations from the app's short-lived dummy context are deliberately not scoped to it — module-level instances must keep their hot-reload resets.
• lifecycle.on_kernel_start cleanup is idempotent (unmount cleanup and kernel-close unregistration may both run).

Two new warnings (once per call site)

1. A Computed created during a render — creates a new Computed, plus registrations and subscriptions, on every render; this was the biggest term of the production leak.
2. A subscription made inside a kernel, outside any render, whose cleanup never ran by kernel close. Render-time subscriptions are component-managed by contract (use_effect cleanups); solara-internal owners mark themselves via _managed_subscription().

Measurements

docs/memory-measurement/leak_canary_app.py (added): a component-body computed capturing a 1 MB payload per render, reading a module-level reactive. 10 pages × 10 cycles, macOS physical footprint:

	idle-point series
before (1.60.1)	122 → 161 → 209 → 247 → 291 → 338 MB (constant ~22 MB/cycle line)
after (this PR)	flat ~130–142 MB for all 10 cycles

Both runs report kernels after close: 0 on every cycle.

The production application (docker rig, real data, playbook cycle protocol): 16.1 MB/cycle → 2.4 MB/cycle with this fix stacked with MALLOC_ARENA_MAX=2 (the residual is bounded thread-pool ramp).

Tests

• test_kernel_close_purges_subscription_residue: fails on master, passes here.
• test_computed_created_during_render_warns, test_unreleased_subscription_warns_at_kernel_close: the new warnings.
• Full unit suite: 414 passed, 23 skipped; toestand suite also green under SOLARA_STORAGE_MUTATION_DETECTION=1.

🤖 Generated with Claude Code