Memory pools may not be released when a node crashes or is dynamically removed

[SaitejaKommi]

Summary

While reviewing the daemon lifecycle, I noticed that memory pools registered by a node appear to remain tracked when that node is removed from a running dataflow or disconnects unexpectedly.

If this observation is correct, repeated node crashes or dynamic node removal could leave stale memory pool registrations until the entire dataflow is destroyed.

Evidence

During RemoveNode cleanup, the daemon removes the node's runtime state and bookkeeping, but I could not find corresponding cleanup for memory pools registered by that node.

Relevant locations:

• binaries/daemon/src/lib.rs

  • DaemonCoordinatorEvent::RemoveNode
  • node cleanup path

• MemoryPoolManager

  • memory pool lifecycle

cleanup_orphans appears to operate at the dataflow level rather than the individual node level.

Possible Impact

If memory pools remain registered after node removal:

• /dev/shm segments may accumulate
• stale pool registrations may persist
• long-running daemons could eventually exhaust the configured pool limit

Suggested Direction

If this behavior is unintended, node removal and unexpected disconnect paths could free any memory pools registered by that node before the remaining bookkeeping is discarded.

I'm happy to investigate further and prepare a PR if this is considered a bug.

[SaitejaKommi]

Hi @phil-opp ,While investigating a possible fix, I realized the memory pool lifetime appears to be decoupled from the sender node's lifetime. A receiver can still legitimately consume and free a pool after the sender has exited, so eagerly cleaning up pools on RemoveNode/EventStreamDropped would break in-flight IPC. It seems this leak (if it exists) may require a different ownership or reclamation strategy (e.g., reference tracking or deferred cleanup). Am I understanding the intended lifecycle correctly?