Hard Runtime Diagnostics interview problem
Event listener registration leak in a collaboration server
Written and reviewed by Sahil Srivastav
This problem is available as the same repository challenge in Python, Java, Node.js, and C++. Open the full problem and choose a language
What this interview round tests
A collaboration server’s active session count returns to normal, but memory and change-delivery work grow all day. Heap captures show closed sessions and their document buffers remaining reachable long after clients disconnect.
This is a hard production-debugging exercise because the retained object is several references away from the global owner, and the same lifecycle bug presents as both memory growth and declining publish performance. It tests whether you can move from operational evidence to a narrow invariant, then make a repair that survives concurrency, retries, failures, or workload growth instead of merely passing one happy-path example.
The scenario
Editing sessions subscribe to a long-lived change bus and receive a registration token. Opening and closing tabs is routine, while the bus itself intentionally lives for the process lifetime.
The lifecycle registers listeners without reliably undoing that registration. The bus retains callbacks, callbacks retain sessions, and every future publish invokes stale listeners in addition to wasting heap.
What you’ll practice
- Following a heap retainer path to a long-lived root
- Pairing listener registration with deterministic unsubscription
- Making close operations safe to repeat
- Distinguishing bounded journals from unbounded listeners
- Testing retention at one and two workload scales
How to approach it
Start from an unexpectedly live session or document buffer and walk referrers upward until ownership becomes intentional. Compare the number of bus registrations with the number of open sessions.
Repair the lifecycle boundary where the server closes a session, preserving ordinary delivery and validation. Verify that both retained-object counts and delivery fan-out return to bounds after repeated open-close cycles.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
Try it in a real repository
LeetCode teaches algorithms. Gronex teaches backend coding rounds with real repositories, failing tests, service logic, and production-style constraints. Read the diagnostic brief on this page, then open the challenge workspace when you are ready to investigate the repository.
FAQ
What should I inspect first in Event listener registration leak in a collaboration server?
Begin with heap histograms, listener counts, retainer paths from document buffers to the process-wide bus, and delivery-to-publish ratios. The supplied evidence narrows the failure mode before you touch the implementation, which is the same evidence-first habit expected during a production incident or senior backend interview.
What makes this a hard runtime diagnostics problem?
It is hard because the retained object is several references away from the global owner, and the same lifecycle bug presents as both memory growth and declining publish performance. The test suite checks the underlying invariant and adverse execution paths, so a local patch or a larger resource limit will not satisfy the challenge.
Which languages can I use for this repository challenge?
The same scenario is implemented in Python, Java, Node.js, and C++. Each language directory includes its own source, evidence or database setup, tests, and verify.sh entry point while preserving the same production invariant.