Investigate: heap corruption / OOM from rapid TLS context churn in monitorNodeCAs during reconnect cycles #288

Summary

Under aggressive replication reconnect cycling, tls.createSecureContext is called repeatedly inside monitorNodeCAs. This has been observed correlating with heap corruption and OOM in production environments.

Current assessment

Believed to be a symptom of the crash-loop / full-copy OOM cycle (see #286) rather than a standalone bug, but the TLS churn may be an independent contributor worth isolating. Nathan and Devin have looked at this but root cause is not confirmed.

Technical detail

• monitorNodeCAs calls tls.createSecureContext on every reconnect attempt
• Under a crash-loop this can happen at high frequency, cycling memory for TLS contexts
• Observed correlating with heap corruption and OOM process crashes

Relation to other issues

• Replication "Requesting full copy of database X from Y" enters a crash loop (event-loop starvation + OOM during full copy) #286: full-copy crash loop (may be the primary cause of the reconnect churn)
• This issue: whether the TLS churn itself is an independent OOM vector

Next step

Confirm whether adding debouncing/caching to monitorNodeCAs's createSecureContext calls reduces or eliminates the heap corruption independent of the full-copy fix.