Runtime Exception Recovery Prompt Template

The exact code block that produced the runtime exception. Must include enough context for the model to understand the logic flow.

def calculate_ratio(a, b): return a / b

Check that the string is non-empty and contains syntactically valid code for the target language. Truncate if it exceeds the model's context window minus other placeholders.

The full runtime exception traceback, including the exception type, message, and stack frames. This is the primary signal for the model to diagnose the root cause.

Traceback (most recent call last): File "app.py", line 5, in <module> result = calculate_ratio(10, 0) ZeroDivisionError: division by zero

Parse the traceback to confirm it contains a valid exception type and at least one stack frame with a file name and line number. Reject empty strings or generic error messages without stack context.

The programming language of the code snippet. Constrains the model's syntax suggestions and library references.

Python

Must match an allowed language from a predefined enum (e.g., Python, JavaScript, Java, Go). Reject unknown or unsupported languages to prevent hallucinated syntax.

The specific version of the language runtime or interpreter. Critical for version-specific exception behavior or deprecated API fixes.

3.11.4

Validate against a known version format for the given language. If null or unknown, the harness should instruct the model to assume the latest stable version and note the assumption in the output.

Optional context such as dependency versions, environment variables, or recent code changes that might be relevant to the exception.

Running inside a Docker container with limited file descriptors. Dependency: requests==2.28.1

Allow null or empty string. If provided, check that it does not contain secrets or PII before sending to the model. Log a warning if the context exceeds 500 characters.

The required JSON schema for the model's response, specifying fields for root_cause, corrected_code, and explanation. Ensures the output is machine-readable for the harness.

{"type": "object", "properties": {"root_cause": {"type": "string"}, "corrected_code": {"type": "string"}, "explanation": {"type": "string"}}, "required": ["root_cause", "corrected_code", "explanation"]}

Must be a valid JSON Schema object. The harness should parse it and confirm the presence of required fields before injecting it into the prompt. Reject if the schema is malformed.

Specific rules the model must follow, such as preserving original function signatures, not introducing new dependencies, or adding specific error-handling patterns.

Do not change the function signature. Add a try-except block to handle the specific exception. Do not use any third-party libraries.

Parse as a list of strings. Check for contradictory constraints (e.g., 'add a new library' and 'no new dependencies'). If constraints conflict, the harness should fail fast and alert the operator rather than sending an ambiguous prompt.

String

Must reference a specific line or function from the provided [TRACEBACK]. Cannot be a generic description like 'a null value occurred'.

String (code block)

Must be syntactically valid in the language of [CODE_SNIPPET]. A parser check must succeed without errors.

String

Must explain how the change in corrected_code directly prevents the exception type identified in [TRACEBACK].

String

Must exactly match the exception class name from the last frame of [TRACEBACK] (e.g., 'NullPointerException', 'TypeError').

Array of Strings or null

If no risks, must be null. If risks exist, each entry must describe a specific edge case not covered by the fix.

Array of Strings

If provided, each alternative must be a distinct, valid code-level strategy. Generic advice like 'add more tests' is not allowed.

Boolean

Must be true if the fix involves authentication, authorization, data deletion, or financial calculation logic; otherwise false.

Corrected code executes without raising the original exception class when run against the reproduction script.

Original exception persists or a new exception of the same class is thrown.

Execute the corrected code in a sandboxed environment with the reproduction script. Assert exit code 0 and no matching exception type in stderr.

Explanation correctly identifies the specific line, variable, or state that triggered the exception, matching the traceback line number.

Explanation blames the wrong line, misidentifies the error type, or provides a generic description without traceback correlation.

Parse the explanation for the file path and line number from the traceback. Use string matching to confirm the error type (e.g., 'AttributeError') appears in the root cause text.

Corrected code passes all existing non-failing test cases and produces semantically equivalent output for normal execution paths.

Fix changes the function's return type, alters side effects, or breaks previously passing unit tests.

Run the existing test suite against the corrected code. Assert that the number of passing tests does not decrease compared to the baseline.

Static analysis and a smoke test reveal no new syntax errors, type mismatches, or unhandled edge cases introduced by the fix.

Linter reports new errors, or a basic smoke test fails on a standard input after the fix is applied.

Run a linter and type checker on the corrected code. Execute a smoke test with a valid input and assert no unhandled exceptions.

Fix includes a null check, bounds check, or try-catch block that prevents the specific exception without swallowing unrelated errors.

Fix uses a bare except clause, catches a base exception class, or silently returns a default value that masks upstream bugs.

Review the diff for exception handling patterns. Flag any bare 'except:' or 'except Exception' clauses that are not re-raising or logging.

Explanation references specific frames, function names, or variable states from the traceback beyond the final line.

Explanation only repeats the error message string without referencing the call stack or intermediate frames.

Check that the explanation text contains at least one function name from a frame other than the bottom-most frame in the traceback.

Response is valid JSON matching the expected schema with non-empty 'corrected_code' and 'root_cause_analysis' fields.

Response is missing required fields, contains unparseable JSON, or places code in the wrong field.

Validate the response against the output schema. Assert all required fields are present and 'corrected_code' is a non-empty string.

For a traceback caused by an out-of-memory kill or a segfault in a C extension, the prompt correctly identifies the limitation and does not produce a hallucinated code fix.

Prompt generates a code change that claims to fix an unrecoverable system-level error without acknowledging the environmental cause.

Supply a traceback from an OOMKill or SIGSEGV. Assert the response contains an escalation or limitation statement and does not modify application logic.