Hard Runtime Diagnostics interview problem
Thread-local retention in pooled workers
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 fixed four-worker payment pipeline completes every request and has no queue backlog, yet heap keeps growing even when idle. Request contexts and diagnostic breadcrumbs remain reachable in proportion to lifetime traffic.
This is a hard production-debugging exercise because the pool and in-flight counts look healthy, and only a heap retainer chain reveals that a small number of immortal workers own a growing history. 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
Pipeline stages access the current request context through per-worker storage. Workers intentionally live for the process lifetime, while each context and its breadcrumb trail belongs to exactly one request.
The starter installs per-request state but does not reliably remove it at request completion. A thread-local root inherits the worker’s lifetime and retains request graphs across an unbounded sequence of tasks.
What you’ll practice
- Following heap references through worker thread-local storage
- Matching request-scoped data to deterministic cleanup
- Clearing state under success, rejection, and exception
- Keeping cleanup bounded during the workload, not just at shutdown
- Testing scale invariance with a fixed worker pool
How to approach it
Start from a retained breadcrumb after the queue drains and walk to the worker that owns it. Distinguish legitimate pool-lifetime structures from request-lifetime objects.
Put setup and cleanup around each request execution boundary and make cleanup unconditional. Sample retention throughout the run as well as at the end so periodic bulk clearing cannot hide continued growth.
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 Thread-local retention in pooled workers?
Begin with live-object histograms, breadcrumb referrer chains, allocation sites, worker-pool size, and retention while and after workloads drain. 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 pool and in-flight counts look healthy, and only a heap retainer chain reveals that a small number of immortal workers own a growing history. 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.