TraceRepair: Automated Trace-Guided Repair

Updated 5 July 2026

TraceRepair is an automated program repair framework that leverages recorded runtime traces and a multi-agent LLM debate to generate and refine patch candidates for Java applications.
The framework uses a trace consistency predicate to ensure patches align with critical execution states, addressing logic errors that standard APR methods miss.
Empirical evaluations on benchmarks like Defects4J show TraceRepair achieves high correct fix counts, demonstrating its effectiveness over traditional APR approaches.

TraceRepair is an automated program repair framework that combines runtime execution traces with a multi-agent LLM committee for debugging and patch synthesis. It was introduced for Java automated program repair as a response to a persistent failure mode of both traditional APR and recent LLM-based APR: complex logic errors and silent failures that compile and execute but return incorrect results, while static context and basic test outputs fail to reveal the underlying runtime behavior. Its defining claim is that runtime evidence should act as objective constraints for patch validation rather than mere additional input, and that candidate patches should be generated, criticized, and refined against those constraints through multi-round debate (Wu et al., 3 Apr 2026).

1. Problem setting and conceptual basis

TraceRepair is motivated by the observation that many APR failures are not syntax errors or immediate exceptions, but logic errors in which the program reaches an incorrect final state while exposing only coarse external feedback such as an assertion failure. In that setting, source code plus test failure messages often do not reveal the actual root cause, and a single LLM can overfit to a plausible but wrong hypothesis, producing patches that satisfy tests by coincidence rather than correct logic (Wu et al., 3 Apr 2026).

The framework therefore shifts the repair basis from static artifacts to recorded execution states. Its runtime trace is modeled as

$\tau = \{ (t, v, val) \mid t \in \text{TimeSteps},\ v \in V_{\text{crit}},\ val \in \text{RuntimeValues} \},$

where the trace records values of critical variables and control decisions during failing executions. In TraceRepair, this trace is not treated as free-form context. It is used through a consistency predicate, so that a hypothesis $h$ is admissible only if $\text{Consistent}(h,\tau)$ holds; critiques are generated only when a candidate patch contradicts the recorded execution (Wu et al., 3 Apr 2026).

This design addresses a common misunderstanding about trace-guided repair. TraceRepair does not merely add runtime logs to a prompt. It treats runtime states as a boundary condition on repair reasoning. A patch that assumes, for example, that a stream advanced when the trace shows skipped = 0 and Action = BREAK is explicitly vulnerable to rejection in debate, even before full validation by regression tests (Wu et al., 3 Apr 2026).

2. Architecture and runtime instrumentation

TraceRepair is organized around a Universal Execution Sandbox and a trace-guided debate system. The sandbox compiles and runs Java programs and tests, supports instrumentation and re-execution, and enforces a 300-second timeout per test run. The debate system consists of a Probe Agent, three specialized repair agents, and a Judge Agent (Wu et al., 3 Apr 2026).

The Probe Agent performs diagnostic probing. It first identifies the failure context from the failing test and any stack trace, then selects suspicious locations $L_{\text{loc}}$ and critical variables $V_{\text{crit}}$ , such as loop counters, condition flags, indices, and return values. It instruments the program by modifying the AST and injecting logging statements around those locations. Each injected probe is wrapped in defensive try-catch, and an adaptive rollback mechanism reverts the code and attempts milder instrumentation if compilation fails (Wu et al., 3 Apr 2026).

Trace volume is explicitly controlled. Logging stops if the trace file exceeds 10MB. Before sending evidence to the LLM, TraceRepair applies tail-biased truncation: if the trace exceeds a prompt budget such as 20KB, only the recent entries near the failure are retained, based on the premise that the most diagnostic states are immediately before the crash or assertion (Wu et al., 3 Apr 2026).

The three repair strategies are heterogeneous by design. The Defensive Strategy assumes environmental instability or unexpected inputs and prefers guards, preconditions, null checks, and boundary checks. The Causal Strategy focuses on the first divergence in the trace and adjusts control flow or core algorithmic logic. The Semantic Strategy reasons about specification and API contracts, asking whether the runtime states violate known semantics such as non-negative lengths or API return conventions. All three agents see the buggy code, failure information, and the runtime trace $\tau$ (Wu et al., 3 Apr 2026).

The Judge Agent is invoked after the debate rounds if no patch passes all tests. It receives the entire history of hypotheses and critiques together with $\tau$ , and synthesizes a final candidate by combining partial insights across strategies while rechecking consistency with the trace (Wu et al., 3 Apr 2026).

3. Debate protocol and repair procedure

TraceRepair’s repair cycle is formalized as a three-phase procedure: diagnostic probing, strategy initialization, and multi-round debate. First, the system instruments the buggy program $P$ , executes the failing tests, and captures $\tau$ . If instrumentation fails entirely, it falls back to a static multi-agent repair regime with $\tau = \emptyset$ (Wu et al., 3 Apr 2026).

Second, each strategy generates $h$ 0 candidate patches from $h$ 1, the chosen strategy prompt, and $h$ 2. These candidates are pre-evaluated in the sandbox, and the strongest candidate per strategy is promoted into the hypothesis set $h$ 3 (Wu et al., 3 Apr 2026).

Third, TraceRepair enters a debate loop of at most $h$ 4 rounds. If any current hypothesis passes all tests, the procedure terminates early. Otherwise, every distinct pair of hypotheses participates in a trace-grounded critique: $h$ 5 Each defender then updates its patch using the accumulated critique set and the trace: $h$ 6 After the final debate round, the Judge Agent performs arbitration and synthesis (Wu et al., 3 Apr 2026).

This debate protocol is narrower than generic multi-agent deliberation. Agents are not asked to criticize style or offer unconstrained alternatives. The instruction is to identify logical contradictions with the recorded execution. This makes debate a logical filtering mechanism rather than a diversity-only ensemble (Wu et al., 3 Apr 2026).

A representative case is Compress-26 from Apache Commons-Compress. The failing test expected 10 bytes to be skipped, but input.skip() returned 0 and the loop broke early. A static LLM-only repair misattributed the fault to arithmetic on numToSkip, even though that line was never reached when skipped == 0. TraceRepair instead surfaced [skipped=0, ..., Action=BREAK], enabling the Causal Strategy to propose falling back to read() when skip() stalls, which matches both the trace and the test expectation (Wu et al., 3 Apr 2026).

4. Evaluation, ablations, and empirical profile

TraceRepair was evaluated on Defects4J v1.2 and v2.0 and on a leakage-controlled Recent-Java dataset. Defects4J v1.2 contains 391 bugs and v2.0 contains 438 bugs. Recent-Java contains 21 single-function bugs from Jsoup, Commons-Lang, and Commons-Compress dated from 2023-09 to 2025-12 (Wu et al., 3 Apr 2026).

Using DeepSeek-V3.2 as backbone, TraceRepair achieved 217 correct / 248 plausible fixes on Defects4J v1.2 and 175 correct / 204 plausible fixes on v2.0, for a total of 392 correct / 452 plausible fixes. This total surpassed REINFIX $h$ 7 at 291 correct / 397 plausible, REINFIX $h$ 8 at 241 / 299, RepairAgent at 164 / 186, and ChatRepair at 162 correct fixes (Wu et al., 3 Apr 2026).

The framework also improved robustness under weaker fault localization. On Defects4J v1.2 single-function bugs, TraceRepair $h$ 9 dropped from 177 correct fixes under perfect fault localization to 171 under method-level fault localization, a 3.39% drop. TraceRepair $\text{Consistent}(h,\tau)$ 0 dropped from 94 to 84, a 10.64% drop. In the same comparison, Codex fell from 99 to 63 and ThinkRepair from 98 to 80 (Wu et al., 3 Apr 2026).

Ablation results isolate the effect of traces and debate. On Defects4J v1.2 single-function bugs with DeepSeek-V3.2, the plain backbone fixed 102 bugs. TraceRepair without trace guidance fixed 154; TraceRepair without debate fixed 158; the full system fixed 177. Removing the Defensive Strategy reduced correct fixes to 166, removing the Causal Strategy to 171, and removing the Semantic Strategy to 169, indicating that all three strategy types contribute (Wu et al., 3 Apr 2026).

Debate itself added measurable incremental value. Starting from 326 correct fixes with direct generation, TraceRepair gained +33 after round 1, +21 after round 2, +8 after round 3, and +4 from Judge arbitration, reaching 392 correct fixes in total (Wu et al., 3 Apr 2026).

The framework was also comparatively efficient. Average usage per bug was 85k tokens, \$\text{Consistent}(h,\tau)$10.014, and 473 seconds for TraceRepair$\text{Consistent}(h,\tau)$2. By comparison, RepairAgent used 270k tokens, \$\text{Consistent}(h,\tau)$30.42 per bug (Wu et al., 3 Apr 2026).

On Recent-Java, the gains generalized beyond benchmark leakage. Vanilla GPT-3.5 fixed 4/21 bugs, ChatRepair$\text{Consistent}(h,\tau)$4 fixed 8/21, and TraceRepair$\text{Consistent}(h,\tau)$5 fixed 10/21. With DeepSeek-Coder, vanilla fixed 2/21 and TraceRepair$\text{Consistent}(h,\tau)$6 fixed 6/21 (Wu et al., 3 Apr 2026).

5. Position within trace-centric debugging and repair research

TraceRepair belongs to a broader shift from pass/fail-driven debugging to trace-centric diagnosis. In automated code repair, TraceCoder organizes debugging as an observe–analyze–repair loop with explicit instrumentation, causal-style trace analysis, historical lesson learning, and rollback, reporting up to a 34.43% relative improvement in Pass@1 over strong baselines and a 65.61% relative gain from the iterative repair process alone (Huang et al., 6 Feb 2026). This suggests a common research direction in which repair systems move from black-box test feedback toward explicit execution models.

At the agent-trajectory level, CodeTracer reconstructs heterogeneous code-agent runs into a hierarchical trace tree and performs failure onset localization, reaching about 46–48% macro F1 while reducing token cost relative to naive prompting, and showing that replaying its diagnostic signals can recover originally failed runs under matched budgets (Li et al., 13 Apr 2026). TraceView complements that line of work with an interactive labeling and visualization system for Thought–Action–Result trajectories in APR agents, emphasizing loops, divergence, misalignment, and feedback misuse in long repair runs (Sajadi et al., 20 Jun 2026).

A nearby methodological parallel appears in REFLECT, which diagnoses a candidate error step in a completed LLM-agent trace, tests that diagnosis through controlled replay with a diagnosis-specific patch, and then uses the verified outcome flip as contrastive evidence to refine attribution (Lin et al., 8 Jun 2026). Another adjacent perspective is TraceGraph, which builds shared decision landscapes over agent trajectories and defines Access, Trap exposure, and Repair as process-level events, then uses historical trap regions to trigger runtime recovery policies (Nian et al., 29 May 2026).

Taken together, these systems indicate a broader convergence: runtime traces, trajectory structure, and replay evidence are increasingly used not only to repair programs, but also to diagnose and repair the behavior of the repair agents themselves.

TraceRepair’s gains are conditioned by the quality of its runtime evidence. The framework depends on tests, and traces are only as informative as the tests that drive execution. Poor coverage yields incomplete traces and weaker guidance. Non-deterministic behavior can also weaken the causal reliability of a single recorded execution (Wu et al., 3 Apr 2026).

The current implementation is Java-specific and benchmarked on Defects4J and Recent-Java. Extending the Probe Agent to other languages requires new instrumentation tooling, and repository-level tasks such as SWE-Bench introduce multi-file traces and much larger execution logs. Tail-biased truncation helps manage prompt budgets, but it can discard early causal context in long traces. Instrumentation and repeated execution also introduce runtime overhead (Wu et al., 3 Apr 2026).

These limitations correct another possible misconception: TraceRepair is not a general guarantee of semantic correctness independent of tests or runtime conditions. It is a test-driven, runtime-grounded APR framework whose strength lies in grounding patch hypotheses in observed execution, not in replacing specification or exhaustive verification (Wu et al., 3 Apr 2026).

The phrase “trace repair” also appears in other technical domains with different meanings. Outside LLM-based APR, it has been used for timed automata repair from timed diagnostic traces (Koelbl et al., 2020), repair of traces against temporal behavior trees in robotics and cyber-physical systems (Schirmer et al., 10 Sep 2025), and sequence reconstruction from multiple noisy traces in DNA storage (Weindel et al., 17 Jul 2025). Those formulations share the broad idea of minimally modifying or reconstructing behavior from traces, but they operate over different objects, constraints, and correctness criteria.

Within automated program repair, however, TraceRepair denotes a distinct framework: runtime execution traces guided automated program repair with multi-agent debate, in which dynamic evidence is promoted from auxiliary context to the central object of repair reasoning (Wu et al., 3 Apr 2026).