Refs are against master 62bf58c0c. These three surfaced in a read-only source audit, each confirmed at the cited lines. None is urgent; together they are the ck-mc process's and store's only unbounded retention I found. One shared module serves every Rust-mode session on the host and runs for days between restarts.
1. transform_session_roots is insert-only
crates/mc-module/src/lib.rs:3628 declares transform_session_roots: Mutex<HashMap<String, HashSet<PathBuf>>>. Transform binds add a per-session entry (:9501-9506, plus :5091/:5115). No production path removes, retains or clears it: grepping production code above the test module for removal on this map finds 0 sites. Route unbind and session.delete leave the entry in place, so resident memory grows with every distinct session the module has ever transformed. This is the one that matters.
2. guidance_dates can outlive a deleted session (narrow)
An entry is inserted when a session has no persisted guidance date yet (:9058-9062). It's removed once a later read finds the date persisted (:9051-9054), or when a transform response commits (:9998-10004). So it only leaks for a session deleted between its first guidance read and its first committed transform. That's a small window, and session.delete / route teardown don't remove the entry. It's minor; I'm listing it because it's the same fix site as 1.
Suggested fix for 1 and 2: evict per-session entries in the same place session.delete and route unbind already clean up. InFlight already has an LRU bound (MAX_IN_FLIGHT_SNAPSHOT_ENTRIES), so there's precedent.
3. mc_changefeed has no retention
crates/mc-store/src/lib.rs:987-996 and :1027-1138 define the changefeed and its appends, and :8111-8157 reads it. Nothing prunes it. It's small today (5,815 rows, feed_seq 1–5,815 on one host with one MODULE-authority project), but it's monotonic, and every Rust-owned memory or note mutation adds a row. Pruning safely needs a consumer watermark, because the host mirror consumes by feed_seq, so this is a small protocol addition rather than a blind DELETE.
Reachability: 1 and 3 grow on any host running rust mode, and 2 needs the narrow ordering above. All three are memory or disk growth over long uptimes, with no correctness impact.
Refs are against master
62bf58c0c. These three surfaced in a read-only source audit, each confirmed at the cited lines. None is urgent; together they are the ck-mc process's and store's only unbounded retention I found. One shared module serves every Rust-mode session on the host and runs for days between restarts.1.
transform_session_rootsis insert-onlycrates/mc-module/src/lib.rs:3628declarestransform_session_roots: Mutex<HashMap<String, HashSet<PathBuf>>>. Transform binds add a per-session entry (:9501-9506, plus:5091/:5115). No production path removes, retains or clears it: grepping production code above the test module for removal on this map finds 0 sites. Route unbind andsession.deleteleave the entry in place, so resident memory grows with every distinct session the module has ever transformed. This is the one that matters.2.
guidance_datescan outlive a deleted session (narrow)An entry is inserted when a session has no persisted guidance date yet (
:9058-9062). It's removed once a later read finds the date persisted (:9051-9054), or when a transform response commits (:9998-10004). So it only leaks for a session deleted between its first guidance read and its first committed transform. That's a small window, andsession.delete/ route teardown don't remove the entry. It's minor; I'm listing it because it's the same fix site as 1.Suggested fix for 1 and 2: evict per-session entries in the same place
session.deleteand route unbind already clean up.InFlightalready has an LRU bound (MAX_IN_FLIGHT_SNAPSHOT_ENTRIES), so there's precedent.3.
mc_changefeedhas no retentioncrates/mc-store/src/lib.rs:987-996and:1027-1138define the changefeed and its appends, and:8111-8157reads it. Nothing prunes it. It's small today (5,815 rows, feed_seq 1–5,815 on one host with one MODULE-authority project), but it's monotonic, and every Rust-owned memory or note mutation adds a row. Pruning safely needs a consumer watermark, because the host mirror consumes byfeed_seq, so this is a small protocol addition rather than a blind DELETE.Reachability: 1 and 3 grow on any host running rust mode, and 2 needs the narrow ordering above. All three are memory or disk growth over long uptimes, with no correctness impact.