Hard Runtime Diagnostics interview problem
Rule bundle reloads never release the previous generation
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 risk service hot-reloads rule bundles successfully, but memory grows with the number of reloads rather than current traffic. Heap evidence shows every historical plugin generation still reachable.
This is a hard production-debugging exercise because the visible active registry looks correct, while hidden references across lifecycle boundaries retain an entire generation graph behind a single callback or cache entry. 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
At any moment, requests should use one active immutable rule generation. Reload builds and publishes the replacement; once in-flight users finish, old loaders, modules, rules, and caches should be collectible.
Long-lived registries, callbacks, or thread-local state keep references to objects owned by previous generations. Replacing the active pointer is insufficient while secondary roots still retain the old object graph.
What you’ll practice
- Reading heap dominators and generation retainer paths
- Separating active configuration from reload history
- Unregistering callbacks and clearing generation-owned caches
- Publishing a replacement without disrupting in-flight work
- Testing retained generations after many reloads
How to approach it
Choose an old-generation object and follow its path to a process-lifetime root. Repeat for more than one object type to find the lifecycle owner rather than patching individual symptoms.
Define what reload must retire in addition to what it activates. Run enough cycles to show retained generation count stays constant while active behaviour and request safety remain unchanged.
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 Rule bundle reloads never release the previous generation?
Begin with generation counts, heap histograms, retainer paths through registries and callbacks, and memory after repeated reload cycles. 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 visible active registry looks correct, while hidden references across lifecycle boundaries retain an entire generation graph behind a single callback or cache entry. 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.