Problem
MpakSource keeps an unbounded module-level Map keyed by registry base URL (src/registries/mpak-source.ts:51). Every distinct base URL the platform fetches from adds an entry that's never evicted.
In practice tenants run 1–3 mpak rows for the lifetime of the process, so this is a tiny leak. But operators reconfiguring NB_REGISTRIES over many process restarts (or pointing at multiple self-hosted mpaks during testing) accumulate entries indefinitely.
Fix
Either:
- Convert to a bounded LRU (cap at e.g. 16 distinct base URLs).
- Move the cache from module scope to per-
MpakSource-instance scope so it's GC'd with the source.
Per-instance is the cleaner architectural shape (matches the source contract), but loses the cross-ConnectorDirectory-call sharing today's module cache provides. LRU keeps cross-call sharing.
Surfaced by
QA review of #195 (Suggestion #1, round 4).
Problem
MpakSourcekeeps an unbounded module-level Map keyed by registry base URL (src/registries/mpak-source.ts:51). Every distinct base URL the platform fetches from adds an entry that's never evicted.In practice tenants run 1–3 mpak rows for the lifetime of the process, so this is a tiny leak. But operators reconfiguring
NB_REGISTRIESover many process restarts (or pointing at multiple self-hosted mpaks during testing) accumulate entries indefinitely.Fix
Either:
MpakSource-instance scope so it's GC'd with the source.Per-instance is the cleaner architectural shape (matches the source contract), but loses the cross-
ConnectorDirectory-call sharing today's module cache provides. LRU keeps cross-call sharing.Surfaced by
QA review of #195 (Suggestion #1, round 4).