No idle grace period before a shared instance is destroyed

[Yaraslaut]

Part of #198 (virtual-actor/actor-sharding survey).

Observation

morph destroys a shared instance immediately at zero attachments, with no idle grace period and no persistence provider — whatever the instance hydrated into memory is discarded the instant the last handler detaches, and the next attach re-hydrates from scratch. Every comparable virtual-actor/actor-sharding system instead keeps an entity resident for some time past its last caller: Orleans defaults CollectionAge to 15 minutes, Akka/Pekko Cluster Sharding defaults idle passivation to 2 minutes, and Cloudflare Durable Objects hibernate "several seconds" after going idle. All three treat minutes-to-seconds-scale residency as the default, not an exotic feature.

The case this bites hardest: a GUI client that reconnects (morph::offline's reconnect path is a first-class morph feature). A single client's connection flapping tears down the shared instance on disconnect and pays full re-hydration cost on the very next attach, even though no other client ever stopped wanting it.

Status: already an explicit deferral in the spec

docs/spec/core/shared_instances.md:455,543 already defers this: "An optional idle grace period … is not part of this work. Default behaviour is immediate destruction at zero." This issue does not propose implementing a grace period now — it re-raises the deferral with the additional evidence that minutes-scale residency is the industry default across Orleans/Akka/Durable Objects, in case that shifts the priority of revisiting it. Nothing has fired the trigger yet; this is filed as a parked marker with an explicit re-entry condition, the same shape as #116-#119 (children of #115).

Revisit only if

Re-hydration cost or reconnect churn shows up as an actual problem in a real example or application — e.g. a model whose hydration does non-trivial I/O (a DB read, a remote call) observed to reconnect/flap often enough that repeated full re-hydration is measurably expensive, or a user-visible report of state loss / latency spikes tied to attach-count transitions through zero.

Verification status

Read directly against master 42deb96: docs/spec/core/shared_instances.md Limitations ("No idle deactivation. Zero attachments destroys immediately; there is no keep-alive, no LRU, no eviction policy") and the lifetime section (:455, :543) documenting the deferral. Comparison figures (Orleans 15 min, Akka 2 min, Durable Objects seconds) are read from each project's own published documentation, not independently benchmarked — see #198 for full citations.

Origin

Surfaced in #198 (survey of morph's instance model against virtual-actor/actor-sharding systems) as "candidate gap G1." The triage comment on #198 judged this the one gap that genuinely matches the #115-sibling "speculative, park with a trigger" shape, since the spec already defers it and no re-entry condition has fired.

[Yaraslaut]

Triage

Verdict: triage: parked.

Checked this against its own claim (that the spec already defers the decision) and against whether the stated re-entry trigger has actually fired anywhere in the tree.

Spec citation verified. Read docs/spec/core/shared_instances.md directly at the cited locations:

• Line 455–457: "An optional idle grace period (keep a zero-count shared instance alive for n seconds in case another client re-attaches) is not part of this work. Default behaviour is immediate destruction at zero."
• Line 543: "No idle deactivation. Zero attachments destroys immediately; there is no keep-alive, no LRU, no eviction policy."

Both are genuine deferrals, not a decision made the other way — the spec explicitly declines to have an opinion here rather than affirmatively choosing immediate-destruction-forever. Nothing in docs/spec/core/shared_instances.md (Design decisions, Limitations, or the lifetime section) treats this as closed.

Trigger has not fired. The issue's own "Revisit only if" condition is: "a model whose hydration does non-trivial I/O … observed to reconnect/flap often enough that repeated full re-hydration is measurably expensive, or a user-visible report of state loss / latency spikes tied to attach-count transitions through zero." Checked the two places this could plausibly show up:

• tests/soak/test_soak_reconnect_churn.cpp (the only test in the tree that flaps reconnects hundreds of times, per docs/spec/testing_strategy.md:161-166) exercises NetworkMonitor → ReconnectCoordinator → SyncWorker and asserts the offline queue drains after every flap. It contains no reference to AllowShared, BRIDGE_MODEL_KEY, or shared-instance directory state at all — it is testing a different subsystem (offline replay correctness), not attach-count-driven instance residency.
• examples/kanban/README.md's "reconnect flap" discussion is about the SyncWorker dead-letter retry cap, not shared-instance destruction/re-hydration.
• examples/bank/README.md's "re-hydrates" is a row-version cache-invalidation pattern for a stale in-memory read inside a live model — unrelated to attach-count reaching zero and the instance being destroyed and recreated.

No open issue, example README, or spec file reports re-hydration cost or reconnect-driven churn against the shared-instance directory as an actual observed problem. Nothing has fired the trigger.

Architecture invariants: none apply forcefully. This isn't a model reaching into the framework (invariant 1), doesn't ask consumers to inherit anything (invariant 2), and isn't a policy-vs-fact conflation (invariant 3) — an idle grace period, if ever added, would live exactly where policy belongs: in the shared-instance directory/lifetime layer itself, not pushed into a value type. It's a genuine deferred design/roadmap question, matching the shape of #115's children (#116–#119), not a mis-framed request or an architecture violation.

Disposition: parked, matching #115/#116-#119's precedent exactly — same label set (enhancement + triage: parked + area: core), same "revisit only if" structure. Leaving open with the re-entry condition as written; nothing to implement now.