Thread Pool Exhaustion Risk Prompt

This prompt is designed for SREs, platform engineers, and performance-focused developers reviewing code changes that create, configure, or interact with thread pools, connection pools, worker pools, or any bounded resource pool. It detects patterns that lead to pool exhaustion under load: unbounded pool growth, missing or infinite timeouts, blocking calls inside pool threads, queue overflow risks, and cascade failure scenarios. Use this prompt during PR review, pre-deployment risk assessment, or capacity planning reviews. It assumes you have access to the relevant code diff, pool configuration files, or runtime metrics. This is not a replacement for load testing or production monitoring; it is a static analysis complement that catches structural risks before they become incidents.

The ideal input is a focused code diff that touches pool creation (new ThreadPoolExecutor, newSemaphore, connection pool configs), task submission (submit, execute), or resource cleanup logic. The prompt works best when you provide the full configuration block—core size, max size, keep-alive, queue type, and rejection policy—along with the task code that runs inside the pool. If you are reviewing a change that adds a new call path through an existing pool, include both the pool definition and the new task code. For connection pools, include the connection acquisition and release patterns. The prompt can also consume runtime metrics (pool size, active threads, queue depth, rejected task counts) when available, which sharpens its saturation risk estimates.

Do not use this prompt for general performance reviews, algorithmic complexity analysis, or single-threaded code paths. It is not designed to find data races, deadlocks, or memory leaks unless those issues directly contribute to pool exhaustion. Avoid using it on codebases where pool management is handled entirely by a framework with known safe defaults (e.g., managed application servers with no custom pool configuration) unless you are specifically auditing a customization. The prompt will flag risks aggressively; it is your job to assess whether a flagged pattern is actually reachable under production load profiles. Always pair the prompt's output with your own understanding of traffic patterns, call graphs, and upstream rate limits. For high-risk services—payment processing, auth, health checks, circuit-breaker paths—require a second human reviewer to sign off on any pool configuration change, even if the prompt scores it as low risk.

This prompt template is designed to be pasted directly into your AI review tool, CI/CD pipeline, or manual code review workflow. It instructs the model to act as a site reliability engineer (SRE) specializing in capacity analysis and cascade failure prevention. The prompt is structured to accept a code diff, relevant configuration files, and deployment context as inputs. It then produces a structured risk assessment with a saturation score, specific findings mapped to code locations, and actionable remediation guidance. The square-bracket placeholders must be replaced with your specific context before use; the prompt will not function correctly if they are left unresolved.

textCopy
You are an SRE and capacity planning engineer reviewing a code change for thread pool, connection pool, or worker pool exhaustion risks. Your goal is to prevent production incidents caused by pool saturation, unbounded queue growth, and cascading thread starvation.

## INPUTS
- **Code Diff:** [CODE_DIFF]
- **Configuration Context:** [POOL_CONFIGURATIONS]
- **Deployment Context:** [DEPLOYMENT_CONTEXT]
- **Expected Load Profile:** [LOAD_PROFILE]

## ANALYSIS INSTRUCTIONS
1.  **Identify All Pools:** Locate every thread pool, connection pool, worker pool, and bounded executor service defined or modified in the diff.
2.  **Analyze Configuration:** For each pool, extract its core, max size, queue type (bounded/unbounded), keep-alive time, and rejection policy.
3.  **Trace Call Paths:** For every task submitted to a pool, trace its execution path to identify blocking I/O calls, long-running computations, or nested pool submissions that could stall a worker thread.
4.  **Assess Cascade Risk:** Determine if a saturated pool can block a request thread, causing upstream backpressure and a cascade failure (e.g., a Tomcat request thread blocked waiting for a saturated JDBC connection pool).
5.  **Calculate Saturation Risk:** For each pool, estimate the time to saturation under the expected load profile, assuming a worst-case task duration.

## OUTPUT FORMAT
Return a single valid JSON object with the following structure. Do not include any text outside the JSON object.
{
  "findings": [
    {
      "pool_name": "string",
      "file_path": "string",
      "line_range": "string",
      "risk_level": "CRITICAL | HIGH | MEDIUM | LOW",
      "saturation_risk_score": 0.0-1.0,
      "finding_summary": "string",
      "cascade_failure_potential": "boolean",
      "remediation": "string"
    }
  ],
  "overall_risk_assessment": "PASS | WARN | FAIL",
  "summary": "A concise executive summary of the top risks."
}

## CONSTRAINTS
- Base your analysis strictly on the provided code diff and context. Do not invent external information.
- If a pool uses an unbounded queue (e.g., `Executors.newCachedThreadPool()` or `Integer.MAX_VALUE`), its risk level must be at least HIGH.
- Flag any blocking operation (I/O, network call, lock acquisition) inside a pool thread as a HIGH risk contributor.
- If a request-handling thread can block on a pool's future (e.g., `future.get()` without a timeout), this is a CRITICAL cascade failure risk.

To adapt this template for your specific environment, replace the placeholders with concrete data. For [CODE_DIFF], provide the unified diff output from your version control system. For [POOL_CONFIGURATIONS], include the relevant sections of application properties, YAML configs, or environment variables that define pool sizes and timeouts. The [DEPLOYMENT_CONTEXT] should describe the service's role, its upstream and downstream dependencies, and the hardware profile (CPU/memory limits). Finally, [LOAD_PROFILE] should specify expected requests per second, average and p99 latency targets, and peak load factors. For high-risk production services, always route the model's FAIL or WARN assessments to a human SRE for final approval before merging the code change.

This prompt is designed to run as a pre-merge gate in CI/CD pipelines, triggered on pull requests that modify thread pool, connection pool, or worker pool configurations. The implementation harness should extract the relevant code diff and any associated configuration files (e.g., application.properties, hystrix.conf, TaskScheduler beans) and pass them as the [CODE_DIFF] input. For Java projects, also include @Bean definitions for ThreadPoolTaskExecutor, ExecutorService instantiations, and any ThreadPoolExecutor constructor calls. For Go, capture ants.NewPool, worker pool patterns, and goroutine lifecycle management near channel-based worker pools. The harness must also supply [LANGUAGE] and [FRAMEWORK] context to enable framework-specific rule activation (e.g., Tomcat connection pool limits, Hystrix timeout defaults, or Node.js worker_threads pool sizing).

Wire the prompt into a validation pipeline with three stages: extraction, analysis, and verification. In the extraction stage, use a lightweight parser or grep-based script to isolate pool configuration blocks from the diff—this prevents sending the entire codebase to the model and reduces token costs. In the analysis stage, call the LLM with the prompt template, setting response_format to JSON Schema matching the expected output structure (fields: pool_analysis, saturation_risk_score, findings, recommendations). Implement a retry wrapper with exponential backoff (3 attempts max) that catches JSON parse errors and schema validation failures. If the model returns malformed JSON after retries, log the raw response and escalate to a human reviewer via the PR comment interface. In the verification stage, run a set of eval assertions against the output: confirm saturation_risk_score is an integer between 0-100, verify that each finding includes a file_path and line_range, and check that recommendations are non-empty when the score exceeds 60. Store the full prompt-response pair in your observability platform for later trace analysis and prompt regression testing.

For high-risk repositories (payment systems, trading platforms, critical infrastructure), add a human approval gate when the saturation risk score exceeds 70 or when the model flags unbounded pool growth. The harness should post a structured comment on the PR with the risk score, top findings, and a clear APPROVE/BLOCK recommendation. Use the model's pool_analysis.capacity_analysis field to generate a capacity chart comment showing projected thread count under peak load. Avoid running this prompt on every commit—trigger it only when files matching patterns like *Pool*.java, *Executor*.go, *worker*.ts, or configuration files with pool-related keys are modified. This targeted execution prevents CI pipeline bloat while catching the highest-risk changes. If your organization uses a centralized pool configuration service, extend the harness to fetch the current production pool settings as [CURRENT_CONFIG] for comparison against the proposed changes.