Memory cache growth during high-frequency v2 topic subscription

Answer to the exact question

In the current Waku v2 (nwaku) release, the cleanup of a peer’s subscription state when a connection drops without a graceful handshake is performed by the underlying libp2p‑GossipSub layer. When a TCP or QUIC stream closes, libp2p emits a peer‑disconnected event; GossipSub immediately removes that peer from all topic meshes and stops forwarding gossip to it. No explicit /v2/subscribe‑unsubscribe handshake is required for this de‑registration.

The message‑deduplication cache that the relay uses is a time‑windowed store. Each seen message is kept for a bounded period (roughly a few minutes, typically 5–10 min depending on the build). After the TTL expires, the cache entry is purged automatically. There is no public, user‑configurable threshold for the cache size; the TTL is hard‑coded in the source and is the only mechanism that bounds heap growth for the deduplication store.

Likely explanation of observed non‑linear heap growth

• Rapid subscribe/unsubscribe churn mainly inflates the per‑topic control‑message queues and the peer‑scoring tables maintained by GossipSub, not the dedup cache itself.
• Memory spikes can also arise from the allocator’s GC pause behaviour in Nim or Go, especially under high message rates.
• If a node is running the optional Waku Message Store (a persistent store), its retention policy is separate from the relay cache and can grow independently if not capped.

Practical steps to verify and mitigate memory growth in your environment

1. Enable metrics – start nwaku with --metrics and expose the Prometheus endpoint. Inspect the waku_relay_seen_cache_size and waku_relay_mesh_peer_count metrics while generating synthetic subscribe/unsubscribe traffic.
2. Check the TTL constant – locate seen_cache_ttl in waku/relay/seen_cache.go (or the Nim equivalent). Verify it matches the expected 5–10 min window. If you need a different TTL, you’ll have to patch the source and rebuild.
3. Profile the heap – run go tool pprof (for Go builds) or Nim’s allocs flag to capture a heap snapshot before and after a forced disconnect. Confirm that the dedup cache entries are released and that peer‑scoring tables shrink.
4. Inspect the message store – if you’re using the optional persistent store, review its --store-max-size and --store-retention flags. These are independent of the relay cache and must be tuned separately.
5. Optional: Upgrade to the latest nwaku release – recent patches have tightened the cleanup of orphaned control‑message queues and added a --max-control-queue-size flag that caps per‑topic control queues.

Missing diagnostic detail that could alter the recommendation

To give a more precise guidance on which exact code paths to inspect (Nim vs Go vs JS), please provide the implementation language and version number you are running.