ORCA: Observability-Grounded Program Repair for Microservice Incidents

ORCA: Observability-Grounded Program Repair for Microservice Incidents Yuanchen Gao1,* , Yifang Tian2 , Yiran Li2 , Charles Zhang1 , Hans-Arno Jacobsen2 1

arXiv:2608.17018v1 [cs.SE] 17 Aug 2026

Hong Kong University of Science and Technology {ygaocv@connect, charlesz@cse}.ust.hk 2 University of Toronto yifang.tian@mail.utoronto.ca, one.li@utoronto.ca, jacobsen@eecg.toronto.edu

SWE-bench, for example, each task provides a repository snapshot and a natural-language GitHub issue, and success is measured by test outcomes [11]. Systems developed for this setting therefore address issue-grounded repository editing, rather than repairs derived from paired telemetry [12]–[14]. Spectrum-based and learned fault localizers similarly rely on test outcomes or explicit failure descriptions [15], [16], while classic APR validates candidate patches against a test suite [17], [18]. Microservice root-cause analysis (RCA) systems take the opposite approach: they consume telemetry and rank suspicious services or call paths [5], [9], but they stop at diagnosis and do not produce repository patches. Configuration repair tools address deployment configuration files [19], but usually analyze those files apart from the log, trace, and metric evidence observed during the incident. As a result, producing a repair patch from telemetry still requires identifying candidate code or configuration locations and defining a validation signal for the observed failure. We propose ORCA, an observability-grounded automated program repair pipeline for microservice incidents. ORCA takes paired failure and reference telemetry bundles, the project workspace when available, and an optional issue title and body. I. I NTRODUCTION For real-incident cases, ORCA sanitizes the issue title and Modern microservice applications are especially prone to body to reduce solution leakage by removing explicit references failures that arise from interactions among many independently to the upstream repair; we refer to the sanitized result as deployed services, configuration files, and runtime dependenthe sanitized issue context. ORCA emits a unified-diff patch cies [1]–[4]. In production, such failures are typically observed candidate for application code or deployment configuration. through telemetry rather than through a failing test: logs ORCA has two stages, as shown in Figure 1. The first expose exceptions and abnormal messages, traces identify stage, Telemetry-Based Fault Localization, compares failure service operations on delayed or failed request paths, and and reference telemetry. The Distillation engine summarizes metrics capture shifts in latency, error rate, traffic volume, and telemetry differences as a compact fault signature. The resource use [5]–[8]. Although these signals support incident Spectrum-based fault localization (SBFL) module uses the diagnosis, they do not directly specify a repair. A telemetry fault signature to rank top-K code candidates, while the anomaly may identify a degraded service or request path [9], Configuration abstractor selects configuration candidates for [10], while the actual fix may require editing an application deployment or telemetry faults. The second stage, Agentic method, a deployment manifest, an environment variable, or Patch Generation and Verification, converts these localized a configuration. The challenge is to map heterogeneous, highcandidates into a patch candidate. It uses a code repair graph volume behavioral evidence to repository locations and to a agent for code candidates, a configuration repair graph agent validation signal for a candidate patch. for configuration candidates, and the Exploration agent when Recent automated program repair (APR) systems are comrepair graph generation does not produce an accepted patch. monly developed and evaluated in issue-to-patch settings. In The resulting patch candidate is evaluated by the TelemetryGrounded Patch Verifier (TGPV), which reports patch validity, * This work was conducted while Yuanchen Gao was an International Visiting Graduate Student (IVGS) at the University of Toronto. syntactic and semantic correctness, test-oracle integrity, and

Abstract—Microservice failures are often diagnosed from operational telemetry. However, automated program repair systems usually start from issue reports, localized code context, or failing tests. This mismatch leaves a gap between telemetrybased diagnosis and patch generation. We present ORCA, an observability-grounded APR pipeline for microservice incidents. ORCA first distills the differences in paired failure and reference telemetry into a fault signature, then uses the signature to identify candidate code and deployment-configuration locations. Repair graph agents and an Exploration agent generate unified-diff patch candidates from these locations. ORCA evaluates generated patches with a Telemetry-Grounded Patch Verifier that separates patch validity, syntactic and semantic correctness, test-oracle integrity, and telemetry replay. On a 575case benchmark, ORCA outperforms all evaluated baselines in terms of cost-effectiveness. Results show that operational telemetry can be transformed from diagnostic evidence into actionable repair context: paired telemetry supports repair-oriented localization, while repair graph agents convert localized code and configuration evidence into constrained patch-generation context for the LLM. Telemetry-grounded verification then exposes repair outcomes that issue- or test-only evaluation would miss. Index Terms—Automated program repair, microservice, observability, fault localization, telemetry-based verification

telemetry replay. TABLE I C APABILITY COMPARISON OF ORCA WITH PRIOR WORK . We evaluate ORCA on a 575-case benchmark spanning synthetic code, synthetic configuration, and real microservice Telemetry- Code Config Code Config Multiincidents, against six representative baselines including issue- System / family grounded FL FL repair repair language driven agentic APR systems. On the synthetic code and SWE-agent [12], [20] × ✓ ✓‡ ✓ ✓‡ ✓ configuration subsets, ORCA obtains the highest counts for the ReAct / single-shot [21] × × × ✓ ✓‡ ✓ reported verification checks among the evaluated systems. On Agentless [13] × ✓ × ✓ × × × ✓ × ✓ × × the 150-case real-incident subset, ORCA produces 113 patches AutoCodeRover [14] GenProg, Prophet [17], [18] × ✓ × ✓ × × that pass patch validity and 45 telemetry-replay mitigations. The ChatRepair [22] × × × ✓ × ✓ evaluated baseline with the highest telemetry-replay-mitigation SBFL [15], [23] × ✓ × × × ✓ ✓ × × × × ✓ count, mini-SWE-agent [20], obtains 74 and 23, respectively, Microservice RCA [7], [9] × × ✓ × × × while using about 640k mean tokens per case compared with Config diagnosis [24]–[26] GLITCH [27] × × ✓ × × × ORCA’s about 26k. InfraFix [19] × × ✓ × ✓ × ORCA makes three contributions: ORCA (ours) ✓ ✓ ✓ ✓ ✓ ✓ 1) A telemetry-to-repair formulation for microservice incidents. ‡ the work can inspect and edit non-code files but can not perform dedicated The formulation starts from paired failure and reference ✓ indicates configuration fault-localization or deployment-configuration repair component. telemetry bundles, distills their behavioral differences into a compact fault signature, and uses the resulting telemetry evidence to derive candidate code and configuration loca- those files apart from incident telemetry. ORCA targets the gap between observability-based diagnosis and end-to-end repair tions. 2) A two-stage repair pipeline for observability-grounded APR. for microservice incidents. The first stage, Telemetry-Based Fault Localization, com- Automated program repair. Recent APR systems are often bines Spectrum-based fault localization with a Configuration developed and evaluated in issue-to-patch settings. SWEabstractor. The second stage, Agentic Patch Generation and bench provides a repository snapshot and a natural-language Verification, uses a code repair graph agent, a configuration GitHub issue, and measures success with test outcomes [11]; repair graph agent, and the fallback Exploration agent to SWE-agent implements an interactive repository-editing agent produce a unified-diff patch candidate under exact-match for this setting [12], [20]. Agentless performs staged localization from files to elements and lines before repair edit constraints and TGPV verification. 3) A telemetry-grounded patch verification and evaluation and uses a SEARCH/REPLACE patch format [13], while procedure. ORCA checks each generated patch along four AutoCodeRover [14] combines code search with localization to axes: patch validity, syntactic and semantic correctness, test- guide repository editing. Conversational repair with compiler oracle integrity, and telemetry replay. The evaluation uses and test feedback [22] and earlier APR methods [17], [18], these checks to compare ORCA and six baselines on a 575- [28] further establish issue- and test-based APR. These systems case benchmark covering synthetic code faults, synthetic are designed around natural-language issue reports, code context, or executable tests, rather than paired failure and configuration faults, and real microservice incidents. The remainder of this paper is organized as follows. § II reference telemetry. ORCA addresses a different input setting: positions ORCA against existing program-repair, RCA, and it starts from paired telemetry bundles and uses telemetrycurrent agentic work. § III and § IV then present ORCA’s two- derived localization to guide and constrain patch generation. stage pipeline. § V describes the datasets, baselines, metrics, It also reports separate patch validity, syntactic and semantic and experimental results. § VI discusses limitations, and § VII correctness, test-oracle integrity, and telemetry replay outcomes rather than a single test-suite result. concludes. Fault localization. SBFL ranks program elements by comII. R ELATED W ORK paring their coverage in failing and passing tests [15], [29]. Table I compares ORCA with representative work from Subsequent work augments SBFL with code and change four areas: APR, fault localization, microservice RCA, and metrics [23], learns feature combinations with deep models [30], configuration diagnosis or repair. These areas address adjacent or uses LLMs to generate fault locations and explanations [16]. parts of observability-grounded repair, but none covers the full These techniques localize faults within code, but their evidence telemetry-to-patch workflow setting. APR systems generate is usually a test outcome or an explicit failure description. patches, but typically assume a natural-language issue, a scoped ORCA uses the same suspiciousness principle with paired code context, or a failing test. Fault-localization techniques failure and reference telemetry: log templates, trace operations, rank suspicious program elements, but usually rely on test and metric series provide the observations used to score code outcomes or explicit failure descriptions. Microservice RCA and configuration candidates. methods consume logs, traces, and metrics, but generally Microservice RCA. Microservice RCA methods use telestop at service- or path-level diagnosis rather than producing metry to identify the service or request path most likely to editable code or configuration changes. Configuration tools explain an incident [31], [32]. Metric-based methods model address deployment configuration files, but usually analyze service dependencies and propagate anomaly scores over

Fig. 1. End-to-end ORCA pipeline

those dependencies [5], [8], [33], while trace-based methods comparison rules. For logs, ORCA replaces volatile fields analyze distributed traces to identify anomalous operations such as timestamps, request identifiers, memory addresses, and or causal paths [6], [7], [34]. These methods are telemetry- hash values with placeholders, groups records by severity and grounded, but their output is diagnostic: a suspect service, message template, and ranks templates by severity and by the operation, or request path. ORCA uses related telemetry difference between their failure-side and reference-side counts. signals for repair-oriented localization. Its scoring incorporates For traces, ORCA groups spans by service and operation, and frequency-aware trace evidence, critical-path latency evidence, ranks each group by three quantities: the failure-reference calland metric anomaly evidence inspired by MicroRank [9], count difference, the latency increase relative to the reference TraceContrast [10], and Baro [35], but maps the resulting side, and the number of error-status spans. For metrics, ORCA evidence to code and configuration locations and then generates ranks service-level series by their deviation from the reference a patch. window, including CPU usage, memory usage, request latency, Configuration diagnosis and repair. Configuration diagnosis and throughput. ORCA applies fixed caps per telemetry source includes analyses that detect misconfigurations from inferred across deployment substrates. constraints or from differences between failing and passing The localization step adapts spectrum-based fault localizaprofiles [24], [25], [36], [37], as well as cross-file analyses that tion [15], [23] from test coverage to failure-reference telemetry. discover correlated configuration dependencies [26], [38], [39]. It defines two candidate types. A code candidate is a method Repair-oriented work detects or repairs defects in infrastructure- in a source file. A configuration candidate is a configuration as-code and deployment configuration files [19], [27], validates file involved in deployment, runtime, or build behavior, such configuration files with LLMs [40], [41], or checks config- as Dockerfiles, Docker Compose files, Kubernetes YAML, uration changes for regressions [42]. These systems usually .env files, collector configurations, shell scripts, or Makefiles. inspect configuration files directly, rather than connecting them ORCA scores code candidates and selects configuration to the log, trace, and metric evidence observed during an candidates separately, as described below. incident. ORCA differs by selecting configuration candidates Code-candidate scoring. ORCA scores each code candidate from incident telemetry and repairing related deployment files from three telemetry signals: logs, traces, and metrics. For within the same patch-generation pipeline. each signal X ∈ {L, T, M }, it computes an Ochiai-based suspiciousness score sX (c) for candidate c [15]: III. T ELEMETRY-BASED FAULT L OCALIZATION Microservice telemetry is valuable for diagnosing production failures, but it does not identify repair locations directly. Logs, traces, and metrics expose abnormal behavior at the level of services, operations, and runtime measurements; a patch, however, must modify a concrete method or some configuration file. ORCA’s telemetry-based fault localization addresses this challenge without invoking a language model. It first compares failure and reference telemetry and summarizes their differences as a compact fault signature. It then scores candidate code and configuration locations from that signature: methods for sourcecode faults and configuration files for deployment or telemetry faults. The resulting candidates provide the patch-generation stage with scoped, telemetry-derived edit locations. Distillation engine. The fault signature is a structured textual summary of the differences between the failure telemetry and the reference telemetry. ORCA groups each telemetry source and orders the groups by deterministic failure-reference

sX (c) = q

ϵX ef (c)

.

X X X (ϵX ef (c) + ϵnf (c))(ϵef (c) + ϵep (c))

Here, ϵX ef (c) denotes failure-side telemetry evidence from signal X attributable to c, ϵX nf (c) denotes failure-side telemetry evidence from signal X not attributable to c, and ϵX ep (c) denotes reference-side telemetry evidence from signal X attributable to c. The score increases when telemetry evidence for c is concentrated on the failure side and is rare or absent on the reference side. Unlike traditional SBFL, which applies Ochiai to test coverage [29], ORCA applies it to telemetry observations, following the code-metric extension of FLUCCS [23]. Log signal treats each severity-ranked message template as an observation. A template associated with candidate c contributes to ϵL ef (c) when it appears on the failure side and to L ϵep (c) when it appears on the reference side. Templates with

higher severity and larger failure-reference count differences therefore contribute more fault evidence.

Algorithm 1 ORCA patch-generation dispatch and verification. Code and configuration repair graph agents use specific prompts, and both may be selected before TGPV verification.

Trace signal scores service-operation groups and adds two refinements to membership counts. First, it weights each trace operation o by the count difference ∆(o) = max(0, nf (o) − nr (o)), where nf (o) and nr (o) are the failure-side and reference-side counts of o [9]. This assigns more evidence to operations whose frequency increases on the failure side than to operations that are common in both runs. Second, for each trace, ORCA computes the span chain with the largest cumulative duration and adds failure-side evidence for candidates on that chain. This captures latency evidence even when an operation appears on both sides of the paired telemetry.

Require: σ fault signature; B ranked code-candidate list with top suspiciousness score smax ; C configuration candidate set; code repair graph agent threshold τ Ensure: patch candidate p and verifier outcomes v 1: P ← ∅ 2: if C ̸= ∅ then P ← P ∪ C ONFIG R EPAIR G RAPH AGENT(C, σ) 3: if smax ≥ τ then P ← P ∪ C ODE R EPAIR G RAPH AGENT(B, σ) 4: if P = ∅ then P ← E XPLORATIONAGENT(σ, B, C) 5: p ← M ERGE(P) 6: if p ̸= ∅ then v ← TGPV(p, σ) else v ← ∅ 7: return (p, v)

Metric signal first ranks CPU, memory, latency, and throughput series by their standardized deviation from the reference window and tests each series for a mean shift beyond the change-point threshold. Operation-tagged series, such as the latency or throughput of a specific endpoint, are attributed to the method implementing that endpoint; series without operation tags are attributed to candidate methods in the affected service. For each attributed series, the contribution to ϵM ef (c) is the standardized deviation from the reference distribution, z(v) = |v − µref |/σref , capped at 5 in the implementation to limit the influence of extreme outliers. If the same series also exhibits a mean shift, ORCA adds one additional failure-side observation to the attributed candidate.

IV. AGENTIC PATCH G ENERATION AND V ERIFICATION

The second stage of ORCA turns telemetry-localized evidence into a patch candidate and then performs telemetrygrounded patch verification (TGPV). Patch generation is agentic because a valid edit may require repository exploration, multifile reasoning, and language-model generation. However, unlike issue-driven agents such as SWE-agent [12] and ReAct [21], ORCA does not start from an unconstrained natural-language prompt. Each model invocation is grounded in the fault signature, the localized code or configuration candidates, and a one-hop repair graph over candidate files and methods. A deterministic dispatcher maps the localization outputs to the patch-generation agents in Algorithm 1. ORCA has The final code-candidate score is the unweighted mean two repair graph agents, one for code candidates and one final (c) = (sL (c) + sT (c) + sM (c))/3. This aggregation keeps for configuration candidates. These agents are not mutually the three telemetry sources on the same Ochiai-normalized exclusive: an incident can require both application-code and scale: logs provide message-level failure evidence, traces deployment-configuration edits, in which case ORCA invokes provide operation-frequency and latency evidence along request both repair graph agents and merges their patch candidates paths, and metrics provide service-level resource and request- into a single patch. The dispatcher routes cases using the localization outputs. behavior evidence. ORCA returns the top-K code candidates, Line 2 invokes the configuration repair graph agent when the with K = 10 in our implementation. configuration candidate set C is nonempty. Line 3 invokes Configuration abstractor. Code candidates do not cover the code repair graph agent when the highest code-candidate faults whose required edit is a Dockerfile, a Kubernetes suspiciousness score smax satisfies smax ≥ τ ; we set τ = 0.60 manifest, a build script, or a collector configuration entry. and keep it fixed across deployment environments. The two The Configuration abstractor handles these cases with an repair graph agents are constrained LLM calls, described below, independent pass over configuration files. ORCA considers and may both contribute patch candidates for the same incident. configuration candidates only when the fault signature suggests If no repair graph agent produces a candidate, Line 4 invokes a deployment or instrumentation fault, optionally supported by the Exploration agent with the fault signature, ranked code the sanitized issue context, rather than a source-code fault. We candidates, and configuration candidates. ORCA launches N use two conditions for this decision: deployment instability, independent Exploration-agent runs and combines their outputs where workloads are not ready and telemetry streams are with file-level majority voting. Line 5 merges the selected missing or incomplete, and series-set expansion, where the candidates into a unified-diff patch candidate; if no agent failure run produces many more distinct metric labels or trace produces a patch, M ERGE returns the empty patch. Line 6 operation names than the reference run. If neither condition applies TGPV only when the merged patch is nonempty and holds, ORCA returns no configuration candidates. Otherwise, otherwise returns empty verifier outcomes. Line 7 returns the it selects all configuration files whose owning service or patch and verifier outcomes. file type matches the fault signature or, when available, the Repair graph agents. Each repair graph agent invoked by the sanitized issue context. The ranked code candidates and the dispatcher issues one LLM call using a specific prompt. The selected configuration candidates are passed to the Agentic code and configuration agents share the same high-level prompt Patch Generation and Verification stage. structure, but differ in their edit context, repair graph summary,

and repair instructions. Each prompt contains five ordered parts: failure-side evidence from the fault signature, a structured edit context derived from localization, target-file context, a textual repair graph summary, and an exact-match edit instruction. The structured edit context is a JSON-formatted object that packages the localization output for the corresponding agent. For code repair, it contains the fault signature σ, the ranked method candidates B with their suspiciousness scores, the affected service when it can be inferred from telemetry, and a repository reference. When a code workspace is available, the tool resolves each candidate to a concrete file:line location; synthetic bundles include this mapping from the injector. For configuration repair, the edit context contains the configuration candidate files in C rather than method candidates. In both repair graph agents, the context defines the target locations the model may edit and the telemetry evidence associated with those locations. The model must return an exact-match search-and-replace edit: the search text must be copied verbatim from the target file, and the replacement text specifies the new content for that region. The agent accepts the output only when the search text matches the target file exactly; otherwise it rejects the edit before verifier execution. Accepted edits are converted into the unified-diff patch candidate returned by the repair agent. Code repair graph. Localization gives the repair agent a ranked list of suspicious methods, but the correct edit may depend on the surrounding call context. The code repair graph therefore augments the top-ranked candidate with one-hop structural context: callers, callees, and textually similar methods, each annotated with its telemetry-derived suspiciousness score. This context helps the model distinguish whether the fault is in the localized method itself, in a caller that passes incorrect inputs, or in a callee whose behavior must be adjusted. The prompt serializes this graph as a short textual summary listing each neighboring method, its score, and its relation to the target. Figure 2(a) illustrates this context for an emailservice fault, where the failure evidence is concentrated on SendOrderConfirmation while related methods provide the edit boundary. Configuration repair graph. Configuration localization returns a set of candidate files rather than a single ranked method, and a correct configuration fix may require coordinated edits across related files. The configuration repair graph groups candidate files that share structural or semantic configuration context, such as the same service, file type, deployment directory, or configuration key. ORCA then selects the group whose file type and service context are consistent with the fault signature and sends all files in that group to one model call. This graph context is needed because configuration faults often span files that do not individually expose runtime divergence but must be edited together. Figure 2(b) shows such a case: the selected co-statement cluster contains multiple service configuration files, while an isolated build script and a co-platform cluster are not selected. Exploration agent. The Exploration agent is the fallback patchgeneration path. It is selected when neither repair graph agent

produces an accepted exact-match patch. This fallback covers faults whose repair location is not recovered by the ranked code or configuration candidates, including semantic faults, naming or convention faults, and build faults outside those candidate sets. The Exploration agent is an interactive repository-level repair agent. Each agent instance operates in a sandboxed repository workspace, with an action space that includes file inspection, repository search, file editing, and validation commands. An instance either produces repository edits that are converted into a unified-diff patch candidate or abstains when it cannot identify a repair location. An empty-edit check rejects outputs with no repository change and treats step-budget exhaustion without edits as an abstention. ORCA can run N independent Exploration-agent instances for the same case. When N > 1, it combines their outputs with file-level majority voting: the selected patch is taken from the instance that edited the file selected by the largest number of instances. Unless otherwise stated, the main experiments use N =1 and an interaction-step budget of B=15 per instance. For configuration-oriented repairs, the Exploration agent can request a bounded set of related configuration files from the configuration repair graph. This allows a local configuration edit to be considered together with files that may require the same change. Telemetry-Grounded Patch Verifier. Given a patch candidate produced by the selected repair agents or the exploration fallback, TGPV verifies whether the patch is usable and whether it mitigates the telemetry fault. A single pass/fail signal is insufficient for microservice repair: a patch may apply but fail to deploy, pass tests only because it weakens the test oracle, or change code unrelated to the request path that triggered the incident. TGPV therefore separates verification into four checks. Patch validity (C1). This check determines whether the generated patch applies to the workspace. TGPV first tries the patch as generated; if it fails, TGPV normalizes common LLM artifacts such as Markdown code-block delimiters and workspace-relative file paths, and then retries with limited fuzz tolerance. Syntactic and semantic correctness (C2). This check is applied after patch validity and evaluates the patch against the correctness criteria provided by the benchmark. In the synthetic code subset, Java instances are checked with their paired fault-revealing unit tests. Python instances are checked against the seeded mutation and the reference pre-injection version; a patch passes C2 when it restores the mutated method with respect to that reference. Accordingly, C2 is reported only for the synthetic code subset, where the benchmark provides these case-specific checks. Test-oracle integrity (C3). This check rejects patches that obtain an apparent test pass by corrupting the test oracle. It flags patches that edit test files, delete @Test annotations, or weaken assertions. Telemetry replay (C4). This check redeploys the patched stack, replays the same traffic profile, and recomputes the

(a) Code repair graph (b) Configuration repair graph Fig. 2. Illustrations of code (a synthetic Python case) and configuration (an example from microservices-demo [4]) repair graphs.

telemetry signal associated with the failure-side fault signature. Telemetry replay is used as a diagnostic signal rather than a complete correctness oracle, so TGPV reports it at two thresholds. C4-strict requires the failure-side signature to drop below 10% of its failure-run baseline while expected-behavior indicators remain above their thresholds. C4-mitigated requires the patch to apply, the workload to deploy, and the failure-side signature to decrease relative to the failure execution. The four checks are reported separately because they capture different failure modes: a patch may apply but fail the casespecific correctness check, preserve the test oracle but leave replayed telemetry unchanged, or reduce the replayed telemetry signal without editing an upstream repair file. V. E VALUATION We evaluate ORCA against the baselines and examine how model and parameter choices affect the observed outcomes through the following research questions: RQ1. How does ORCA compare against six baselines on filelevel localization and patch-verification outcomes across code, configuration, and real-incident subsets? RQ2. How sensitive are the results to the LLM backbone? RQ3. How does the number of Exploration-agent runs N affect reported repair outcomes and token cost? RQ4. How sensitive are the results to LLM temperature, i.e., the decoding temperature used during generation? We also report a controlled ablation (Section V-H) that removes both the fault signature and the sanitized issue context derived from the issue title and body, isolating their joint contribution. A. Datasets Our benchmark contains 575 microservice failure cases from three sources and will be made publicly available. Each case is the unit of evaluation, including a paired telemetry bundle collected from a failure execution and a reference execution under the same workload and five-minute time window. Synthetic code subset (200 cases). This subset isolates the code-repair path. Following the controlled fault-injection model in the RCAEval benchmark [8], the injector instantiates faults from twelve families across two widely used microservice systems, yielding 200 cases: six families in the Python code of Online Boutique (OB) [4] and six in the Java code of TrainTicket (TT) [1]. Because each fault is injected deterministically, the inverse of the injected edit provides the ground-truth repair for each case.

Synthetic configuration subset (225 cases). This subset specifically addresses configuration repair. We construct 225 controlled cases, each obtained by changing a single field in a single deployment resource; the reference repair is the inverse of the injected field change. The injected faults follow the categories of AIOpsLab [43], spanning scheduling, resource limits, images, commands, probes, and routing. We apply these faults to four microservice testbeds: two applications in DeathStarBench [2], OpenTelemetry Demo [3], and a TiDB operator deployment [44]. Real-incident subset (150 cases). This subset combines 56 reproduced real incidents with 94 controlled mutation variants derived from seed incidents. The 56 reproduced incidents are drawn from fixed issues in four open-source repositories: microservices-demo [4], opentelemetry-demo [3], train-ticket [1], and DeathStarBench [2]. For each issue, we identify the versions immediately before and after the repair and deploy both in containerized environments. We include a reproduced incident only when it satisfies four criteria: telemetry is available from both the faulty and fixed executions; the faulty revision has a materialized workspace; the groundtruth fix location contains between 1 and 12 substantive files; and the localization pool contains at least 100 candidate snippets. The included incidents span eight source languages and fourteen ground-truth file types, including source files, Dockerfiles, shell scripts, Makefiles, docker-compose files, Kubernetes YAML, and .env files. The mutation portion adds 94 controlled variants derived from nine real-incident seed cases by preserving the original fault pattern while changing the concrete program or configuration element that instantiates the fault, such as string constants, Boolean settings, numeric parameters, ports, timeouts, identifiers, or configuration keys. Before running any system, we sanitize each benchmark bundle to remove direct repair hints. Removed fields include issue or pull-request identifiers, upstream repair titles, groundtruth file paths, injected fault labels, and per-snippet groundtruth labels. B. Baselines We compare ORCA against six baselines, all run on the same model at temperature 0 and low reasoning effort. Direct is a single LLM call that receives the fault signature but no localized candidates or interaction loop. One-Shot is a single LLM call augmented with the top-five localized candidates selected by ORCA’s localization stage. ReAct [21] is a bounded tool-use loop with read file, search, list dir, and submit patch actions,

capped at eight steps. Agentless [13] is the upstream hierarchical 1) Synthetic code subset (200 cases): The left half of Table II localizer and repair pipeline, which refines the search from summarizes the synthetic code subset. ORCA emits patches files to program elements and then to lines before applying for 197 of 200 cases and obtains File hits in 193 cases. On its SEARCH/REPLACE post-processor. AutoCodeRover [14] OB-Python, ORCA matches AutoCodeRover on patch validity is a structure-aware repair agent that uses abstract syntax and obtains higher syntactic and semantic correctness and tree (AST) code-search APIs with iterative context retrieval. telemetry replay counts. On TT-Java, where Agentless and Both released implementations use Python-specific localization AutoCodeRover are not applicable, ORCA obtains the highest components; in the synthetic code subset, we therefore run patch validity and syntactic and semantic correctness counts them only on the Python cases and, in the real-incident subset, among the evaluated systems. treat them as Python-only baselines. mini-SWE-agent [20] is a The comparison shows that a File hit does not necessarily shell-loop repair agent; it edits files directly and emits git diff correspond to a verified repair. Direct, One-Shot, and ReAct on completion, using the SWE-bench-style task prompt for often produce File hits, but few of their emitted diffs pass the which it was designed. ORCA is the full pipeline of Section III. patch-validity check, which limits their syntactic and semantic All baselines and ORCA receive the same fault signature and, correctness and telemetry replay outcomes. Agentless emits when the issue title and body are available, the same sanitized edits against paths that do not match the injection workspace issue context. in these runs, yielding no diffs that pass the patch-validity check. mini-SWE-agent is language-agnostic, but obtains lower verification counts than ORCA on both OB-Python and TTC. Metrics Java. AutoCodeRover is competitive on OB-Python, but its We report effectiveness and efficiency metrics. Following released localization components are Python-specific and it is § IV, the tables and figures use C1–C4 to denote the four TGPV not evaluated on TT-Java. Overall, the synthetic code results checks. Effectiveness is reported primarily with patch validity indicate that ORCA’s advantage comes less from file-level (C1), syntactic and semantic correctness (C2), and telemetry localization alone than from converting localized telemetry replay (C4). We report test-oracle integrity (C3) separately evidence into patches that pass patch validity and satisfy the to identify patches that edit tests, remove test annotations, or available repair checks. weaken assertions instead of repairing the fault. Efficiency is Dispatch and cost. The dispatcher sent 77 of the 200 cases reported as average token cost and wall-clock time per case. For to the repair graph agents, where each case uses one bounded real incidents, where exact patch equivalence is not generally LLM call (about 10k median tokens). The remaining 123 well-defined, we also report File hit, a file-level localization cases entered the Exploration agent: 103 completed through measure indicating whether the patch touches a file modified the default N =1 exploration run with the secondary tool-use by the upstream repair. All applicable baselines use the same loop, while 20 terminated after abstaining or producing an metric definitions. empty patch. This routing explains the two-level token-cost Primary real-incident metrics. For the synthetic subsets, distribution: repair graph cases require one bounded model call, injected faults provide known ground-truth files or reference whereas exploration-agent cases incur additional workspaceedits. For real incidents, exact textual patch matching is search and editing steps. not generally well-defined because a generated patch may Limited telemetry signal in TT-Java. The TT-Java value address the same incident through a different but semantically faults change returned values but produce little observable equivalent edit. We therefore report File hit as only a file-level change in the collected logs, traces, or metrics. Repeated paired localization measure, use patch validity to record whether the collections also showed no separable telemetry difference for generated diff applies to the checked-out workspace, and use this fault class. We therefore treat the test-based syntactic telemetry replay as a separate runtime diagnostic. and semantic correctness check as the primary TT-Java repair Telemetry replay uses the C4-strict and C4-mitigated thresh- outcome and interpret telemetry replay for TT-Java cautiously. olds defined in § IV. Cases without separable failure/fixed ORCA emits patches for 98 of 100 cases and obtains File hits telemetry are marked inconclusive and omitted from C4 totals. in 94, but only 32 patches both pass patch validity and compile; For cross-baseline telemetry comparison, we use C4-mitigated among these, 30 pass the tests. The second-highest test-pass and report C4-strict as the stricter diagnostic. A patch may count is mini-SWE-agent’s 17. These results indicate that, for satisfy telemetry replay without a File hit when it changes TT-Java, File hit is high but many generated patches do not the same fault-propagation path through a different file or reach the syntactic and semantic correctness check because location. Such File-miss telemetry-replay outcomes require they fail patch validity or compilation. 2) Synthetic configuration subset (225 cases): The right separate reporting and case-level interpretation; Section V-I half of Table II reports results for the synthetic configuration gives an example. subset. ORCA’s repair graph agents produce 213 patches that pass patch validity (95 %), compared with 177 for mini-SWED. RQ1: Cross-baseline comparison agent, 30 for ReAct, and 40–41 for Direct and One-Shot. RQ1 evaluates ORCA and six baselines on the full 575-case ORCA also obtains 131 strict telemetry-replay cases (58 %) benchmark using DeepSeek-V4-pro [45] with temperature 0. and 210 mitigated telemetry-replay cases (93 %). The highest

TABLE II R ESULTS ON SYNTHETIC SUBSETS . L EFT: 200 SYNTHETIC CODE FAULTS . R IGHT: 225 SYNTHETIC CONFIGURATION FAULTS . Synthetic code subset (200)

Synthetic config subset (225)

OB-Python (100) Method

Emitted patches

File hit Tokens Time (s) C1 C2 34 1 1 5 96 0

24 1 1 1 56 0

TT-Java (100)

C3 C4 C1 C2 100 100 100 100 100 100

C3 File hit

mini-SWE-agent ReAct Direct One-Shot AutoCodeRover Agentless

63/200 184/200 162/200 168/200 96/100 73/100

63/200 177/200 160/200 149/200 96/100 73/100

23.1k 18.0k 3.5k 3.7k 37.0k 9.1k

373 149 65 66 221 155

29 25 17 99 1 4 2 99 1 0 0 100 2 0 0 99 83 n/a n/a n/a 0 n/a n/a n/a

ORCA

197/200 193/200

34.0k

167 96 58 100 95 71 30 100

177 207 218 215 n/a n/a

C1

C4s C4m

177 30 41 40 n/a n/a

110 38 24 21 n/a n/a

207 213 131

Tokens Time (s)

174 113.4k 57 42.0k 37 6.2k 34 5.0k n/a n/a n/a n/a

58.3 77.7 63.5 47.5 n/a n/a

210

93.5

35.5k

Notes: C4s/C4m denote strict/mitigated telemetry replay. Token consumption and time are per-case averages.

corresponding baseline counts are from mini-SWE-agent, with ReAct produce few telemetry-replay mitigations. Agentless and 110 strict and 174 mitigated telemetry-replay cases. AutoCodeRover are limited by their Python-specific localization Direct, One-Shot, and ReAct obtain high File hit counts and repair components; the real-incident subset also includes (207–218 of 225 cases), but only 30–41 of their patches pass non-Python source files and deployment-configuration repairs, patch validity. Thus, many baselines identify the affected so these systems cover only part of the subset’s repair space. To assess whether telemetry replay check (C4) reflects meanconfiguration file without producing an applicable deploymentconfiguration patch. The fault signature often provides enough ingful fault mitigation rather than only changes to telemetry service or file context for file-level localization, but the emission, we manually inspected the 45 ORCA patches that generated diffs frequently fail before telemetry replay can satisfied strict or mitigated telemetry replay on the real-incident evaluate them. Agentless and AutoCodeRover are not evaluated subset. We compared each generated diff with the issue title on this subset because their released pipelines target Python and body, the upstream repair, and the replayed fault signature, code rather than deployment-configuration repair. ORCA and checked whether the edit corrects, removes, or disables the reaches a 9.9k-token median cost (mean 35.5k, increased by the fault-related code path, deployment-configuration key, telemetry 20 % of cases routed to the exploration agent), with about one- key, or instrumentation setting. This inspection finds that 31 third of mini-SWE-agent’s mean token cost while producing of the 45 telemetry-replay mitigations are fault-addressing patches, including 11 File hit cases and 20 File miss cases. The more mitigated telemetry-replay cases. 3) Real-incident subset (150 cases): The real-incident subset remaining 14 cases reduce the replayed fault signature but are contains the 56 reproduced real incidents and the 94 mutation not counted as manually confirmed repairs. This result supports variants described in Section V-A. Figure 3 reports file-level using C4 as evidence that a patch can address or partially localization, patch validity, telemetry replay, and token cost mitigate the observed fault, while C4 remains a diagnostic signal rather than a complete correctness oracle. for this subset. ORCA produces 113 patches that pass patch validity, 45 telemetry-replay mitigations, and 16 strict telemetry-replay E. RQ2: Sensitivity to the LLM backbone cases. The corresponding counts for mini-SWE-agent are 74, RQ2 evaluates model sensitivity on the 150-case real23, and 7. Relative to mini-SWE-agent, ORCA obtains 1.53 incident subset. We compare seven LLMs from four providers: times as many patches that pass patch validity, 1.96 times as DeepSeek-V4-pro, DeepSeek-Flash, Claude-Opus-4.8, GPTmany telemetry-replay mitigations, and 2.29 times as many 5.1, GPT-5-mini, GPT-4o-mini, and Qwen3-Coder-30B [45]– strict telemetry-replay cases. Its mean token cost is also lower: [51]. We keep the ORCA pipeline, prompts, input data, 26k tokens per case, compared with 640k for mini-SWE- temperature, and reasoning effort fixed, using temperature 0 agent. This comparison shows that, on the real-incident subset, and low reasoning effort for all models, and vary only the ORCA improves the observed verification outcomes while LLM models(Table III). Across these models, File hit ranges using substantially fewer tokens per case. from 41 to 57 cases, patch validity from 113 to 127 cases, Despite having fewer File hits than mini-SWE-agent (49 and telemetry-replay mitigations from 37 to 45 cases. Claudeversus 58), ORCA produces more applicable patches and Opus-4.8 obtains the highest File hit and patch-validity counts, more telemetry-replay mitigations. One reason is that File while DeepSeek-V4-pro and GPT-4o-mini obtain the highest hit does not capture alternate-location repairs: for example, telemetry-replay mitigation count. Section V-I shows a configuration patch that edits a different The larger variation is in token cost. Mean tokens per case file from the upstream repair while disabling the same faulty range from 6.9k with GPT-4o-mini to 26.4k with DeepSeekinstrumentation. More generally, ORCA’s repair graph agents V4-pro, a 3.8 times difference. In this experiment, changing the convert localized candidates into patches that pass patch validity LLM backbone changes token cost more than the reported File more often than the evaluated baselines. Direct, One-Shot, and hit, patch-validity, and telemetry-replay mitigation counts. This

AutoCodeRover

640 26

109

102 31

23 (15%) 16

ORCA (ours)

101

1

1

0

1 2

7

19

tokens/case (k)

74 (49%)

74 (49%)

45 (30%)

113 (75%)

58 (39%)

60 40

0

mini-SWE 103

20 26

27 29

100 50

1

1

0

19 (13%)

40

ReAct

80

150 49 (33%)

60

6 (4%) 5 (3%)

# cases

80

Agentless

14

200

100

20

One-Shot

8 7

Direct

(a) File hit, C1 patch validity, and C4 telemetry replay outcomes (b) Tokens/case (c) Mitigated telemetry replay vs. tokens per case Fig. 3. Results of seven systems on the real-incident subset (150 cases). For telemetry replay outcomes, faded bars denote mitigated telemetry replay and solid bars denote strict telemetry replay.

TABLE III LLM- BACKBONE SENSITIVITY ON THE REAL - INCIDENT SUBSET.

G. RQ4: Sensitivity to LLM temperature

RQ4 evaluates sensitivity to LLM temperature on the 150case real-incident subset. We keep the ORCA pipeline, input data, and LLM backbone fixed, and vary only the temperature Claude-Opus-4.8 57 127 43 14.5k from T =0 to 0.9 using gpt-4o-mini, which supports the temGPT-5.1 52 121 43 11.1k perature range used in this experiment. For each temperature, DeepSeek-V4-pro 49 113 45 26.4k Qwen3-Coder-30B 52 117 43 10.5k we use R=3 random seeds for generation metrics; telemetry DeepSeek-Flash 49 117 37 20.1k replay is measured once per temperature. GPT-5-mini 41 116 44 14.9k Across the temperature range, patch generation remains GPT-4o-mini 41 120 45 6.9k near 100 %. Patch validity stays within 120–123 cases, File hit within 41–46 cases, and telemetry-replay mitigations within 41– 49 cases (Figure 4(a)–(b)). Mean token cost remains between pattern is consistent with ORCA’s telemetry-localized repair 6.7k and 7.0k tokens per case. Strict telemetry-replay counts setting. Telemetry-Based Fault Localization identifies candidate range from 9 to 14 cases, with the lowest value at T =0.9. code and configuration locations from telemetry-derived evi- Overall, the measured outcomes vary within a narrow range dence, and the repair graph agents package these locations with across the evaluated temperature settings. We use T =0 in the local code or configuration context and repository-structure other experiments to keep generation deterministic. relations. The LLM backbone is therefore asked to synthesize an exact-match edit within a constrained repair context, rather H. Ablation: contribution of the fault signature and issue than to infer repair locations primarily from the issue title context This ablation study isolates two sources of repair context and body and the repository. Model choice still affects cost in the real-incident pipeline: the fault signature derived from and some outcomes, but on this subset the evaluated models paired failure and reference telemetry, and the sanitized issue produce similar File hit, patch-validity, and telemetry-replay context derived from the issue title and body. We rerun the mitigation counts under the same ORCA pipeline. 150-case real-incident subset with both inputs removed from the full pipeline, including localization and patch generation, F. RQ3: Effect of the Exploration-agent run count N keep the rest of the pipeline configuration fixed, and compare RQ3 evaluates the Exploration-agent run count on real- this variant with full ORCA (Figure 4(c)). Removing these incident cases routed to this stage. Of the 150 cases in the inputs reduces all reported repair outcomes: File hit decreases real-incident subset, 40 are routed to the Exploration agent. from 49 to 8, patch validity from 113 to 40, and telemetryOn these 40 cases, we compare N ∈ {1, 3, 5} and combine replay mitigations from 45 to 13. Mean token cost increases multiple runs using the file-level voting rule of Section IV, from 26k to 58k tokens per case, consistent with additional keeping the model (GPT-5-mini), prompts, and inputs fixed. workspace exploration before patch generation. These results Increasing N improves several repair outcomes. File hit rises indicate that the distilled fault signature and sanitized issue from 4 at N =1 to 10 at N =3 and 11 at N =5, while patch context provide useful repair context for both localization and validity rises from 28 to 35 at N =3 and remains above the N =1 patch construction. setting at N =5. Telemetry-replay mitigations remain similar at 7–8 cases. The improvement comes at higher aggregate cost I. Case study over the 40 routed cases: token use increases from 1.6M to Telemetry mitigation with a File miss. Telemetry replay can 4.5M tokens, or 2.81 times. We therefore use N =1 elsewhere also identify mitigations that are not counted by the File hit in the evaluation for efficiency. metric. Issue #1468 of opentelemetry-demo [52] is one such Model

File hit/150

C1/150

C4-mit.

Tokens

100 80 60 40 20 0

(b) C4 telemetry-replay C4-mit. C4 strict # cases (C4, seed r1)

% of 150 cases

(a) generation metrics (R=3) emit C1 File hit

0

0.3

0.5

0.7

0.9

LLM temperature

(c) ablation Full ORCA Ablation study 113

120 50 40 30 20 10 0

80

58k

49

40

45

40

26k 13

8

0

0.3

0.5

0.7

0.9

0 File hit

C1

C4-mit

Tokens

LLM temperature

Fig. 4. Effect of LLM temperature on (a) generation metrics and (b) telemetry-replay check. (c) Ablation of the fault signature and issue context.

case (Figure 5). The frontend’s filesystem auto-instrumentation emits many additional fs spans, which dominate the trace stream. The upstream repair disables this instrumentation in the frontend Node SDK code, whereas ORCA’s configuration repair graph agent disables the same instrumentation through the documented deployment environment variable. The two patches therefore edit different files, but they target the same telemetry source. Under telemetry replay, the fs-span fault signature decreases from 1.0 to 0.0, while the expectedbehavior score remains 1.0. Because the ORCA patch edits a different file from the upstream repair, it is counted as a File miss; telemetry replay, however, records the reduction in the fault signature as a mitigation. VI. D ISCUSSION Figure 6 partitions the 150 real-incident cases by patch validity, File hit/File miss status, and telemetry-replay outcome. The breakdown clarifies how file-level localization and telemetry replay provide different evidence about generated patches. Metric interpretation. File hit is useful for interpreting whether a patch overlaps the upstream repair files, but not exactly a correctness measure. ORCA obtains File hits in 49 cases; 40 of these patches pass patch validity, and 15 of the valid File hit patches satisfy strict or mitigated telemetry replay. Conversely, 30 valid File miss patches satisfy strict or mitigated telemetry replay, and the manual inspection reported in RQ1 labels 20 of them as fault-addressing patches. These outcomes indicate that File hit and telemetry replay should be reported separately: the former measures file-level overlap with the upstream repair, while the latter measures reduction of the fault-signature telemetry. Failure modes. The two largest remaining categories are File miss patches with no telemetry mitigation (43 cases, 29 %) and no valid patch (37 cases, 25 %). The first category points to localization gaps in telemetry-sparse or multi-language cases; the second points to patch-construction failures, especially generated patches that fail the validity check. Internal threats to validity. Telemetry replay can credit patches that alter telemetry emission rather than repair the root cause, and can be inconclusive when a fault lacks a detectable telemetry signature. We mitigate this risk by reporting both strict and mitigated telemetry replay, separating File miss telemetry-replay outcomes from File hits, and manually inspecting the telemetry-replay mitigations in RQ1. Sensitivity to

LLM backbone, Exploration-agent run count, and temperature is reported in RQ2–RQ4. External threats to validity. The benchmark draws on four open-source microservice projects and covers both code-level and deployment-configuration faults. The conclusions may not transfer unchanged to systems with different deployment substrates, proprietary operational practices, or telemetry coverage. The ablation further shows that removing the fault signature and sanitized issue context substantially reduces repair outcomes on this benchmark; this dependence may differ when the issue title and body are absent or uninformative. Of the 150 real-incident subset cases, 94 are mutation variants derived from the collected real incidents. The aggregate results should therefore be interpreted as combining reproduced incidents with controlled variants, rather than as 150 independently observed incidents. Finally, the telemetry comes from reproduced workload replay rather than production traffic, and replay-environment drift may affect telemetry-replay outcomes. VII. C ONCLUSION This paper presents ORCA, an observability-grounded repair approach for microservice incidents. ORCA derives a fault signature and candidate code and deployment-configuration locations from paired failure and reference telemetry, generates unified-diff patch candidates through repair graph agents and exploration, and evaluates them with TGPV checks. Across a 575-case benchmark spanning synthetic code faults, synthetic configuration faults, and real microservice incidents, ORCA produces more patches that pass patch validity and more telemetry-replay mitigations than the evaluated baselines, while using substantially fewer tokens than the strongest agentic baseline on the real-incident subset. These results show that operational telemetry can be transformed from diagnostic evidence into actionable repair context: paired telemetry supports repair-oriented localization, while repair graph agents convert localized code and configuration evidence into constrained patch-generation context for the LLM. Telemetry-grounded verification then exposes repair outcomes that issue- or testonly evaluation would miss. R EFERENCES [1] X. Zhou, X. Peng, T. Xie, J. Sun, C. Ji, W. Li, and D. Ding, “Fault analysis and debugging of microservice systems: Industrial survey, benchmark system, and empirical study,” IEEE Transactions on Software Engineering, vol. 47, no. 2, pp. 243–260, 2021.

Upstream repair — src/frontend/. . . /Instrumentation.js

ORCA — docker-compose.yml

’@opentelemetry/instrumentation-fs’: { requireParentSpan: true, + enabled: false,

environment: - WEB_OTEL_SERVICE_NAME=frontend-web + - OTEL_INSTRUMENTATION_FS_ENABLED=false

Fig. 5. Incident #1468 of opentelemetry-demo: ORCA changes deployment configuration and reduces the replayed fs-span fault signature without a File hit.

File hit · strict replay 8 (5%) File hit · mitigated replay 7 (5%) File hit · no mitigation 25 (17%) File miss · strict replay 8 (5%) File miss · mitigated replay 22 (15%) File miss · no mitigation 43 (29%) no valid patch 37 (25%)

Fig. 6. Outcome breakdown for ORCA on the real-incident subset

[2] Y. Gan, Y. Zhang, D. Cheng, A. Shetty, P. Rathi, N. Katarki, A. Bruno, J. Hu, B. Ritchken, B. Jackson et al., “An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems,” in Proceedings of the twenty-fourth international conference on architectural support for programming languages and operating systems, 2019, pp. 3–18. [3] O. Project, “OpenTelemetry Demo: A reference distributed application built with opentelemetry instrumentation,” https://github.com/ open-telemetry/opentelemetry-demo, 2026. [4] Google Cloud Platform, “Online boutique (microservices-demo): A cloud-first microservices demo application,” https://github.com/ GoogleCloudPlatform/microservices-demo, 2026. [5] L. Wu, J. Tordsson, E. Elmroth, and O. Kao, “Microrca: Root cause localization of performance issues in microservices,” in IEEE/IFIP Network Operations and Management Symposium (NOMS), 2020, pp. 1–9. [6] C. Lee, T. Yang, Z. Chen, Y. Su, and M. R. Lyu, “Eadro: An end-to-end troubleshooting framework for microservices on multi-source data,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2023, pp. 1750–1762. [7] G. Yu, P. Chen, Y. Li, H. Chen, X. Li, and Z. Zheng, “Nezha: Interpretable fine-grained root causes analysis for microservices on multi-modal observability data,” in Proceedings of the 31st ACM joint European software engineering conference and symposium on the foundations of software engineering, 2023, pp. 553–565. [8] L. Pham, H. Zhang, H. Ha, F. Salim, and X. Zhang, “RCAEval: a benchmark for root cause analysis of microservice systems with telemetry data,” in Companion Proceedings of the ACM on Web Conference 2025, 2025, pp. 777–780. [9] G. Yu, P. Chen, H. Chen, Z. Guan, Z. Huang, L. Jing, T. Weng, X. Sun, and X. Li, “MicroRank: End-to-end latency issue localization with extended spectrum analysis in microservice environments,” in Proceedings of the Web Conference 2021, 2021, pp. 3087–3098. [10] C. Zhang, Z. Dong, X. Peng, B. Zhang, and M. Chen, “Trace-based multidimensional root cause localization of performance issues in microservice systems,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024, pp. 1–12. [11] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. R. Narasimhan, “SWE-bench: Can language models resolve real-world github issues?” in The Twelfth International Conference on Learning Representations, 2024. [Online]. Available: https: //openreview.net/forum?id=VTF8yNQM66 [12] J. Yang, C. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “SWE-agent: Agent-computer interfaces enable automated software engineering,” Advances in Neural Information Processing Systems, vol. 37, pp. 50 528–50 652, 2024. [13] C. S. Xia, Y. Deng, S. Dunn, and L. Zhang, “Demystifying llm-based software engineering agents,” Proceedings of the ACM on Software Engineering, vol. 2, no. FSE, pp. 801–824, 2025. [14] Y. Zhang, H. Ruan, Z. Fan, and A. Roychoudhury, “AutoCodeRover: Autonomous program improvement,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 1592–1604. [15] R. Abreu, P. Zoeteweij, and A. J. Van Gemund, “On the accuracy of spectrum-based fault localization,” in Testing: Academic and industrial

conference practice and research techniques-MUTATION (TAICPARTMUTATION 2007). IEEE, 2007, pp. 89–98. [16] S. Kang, G. An, and S. Yoo, “A quantitative and qualitative evaluation of llm-based explainable fault localization,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 1424–1446, 2024. [17] C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, “Genprog: A generic method for automatic software repair,” IEEE Transactions on Software Engineering, vol. 38, no. 1, pp. 54–72, 2012. [18] F. Long and M. Rinard, “Automatic patch generation by learning correct code,” in Proceedings of the 43rd annual ACM SIGPLAN-SIGACT symposium on principles of programming languages, 2016, pp. 298– 312. [19] N. Saavedra, J. F. Ferreira, and A. Mendes, “InfraFix: Technologyagnostic repair of infrastructure as code,” in Proceedings of the 34th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2025, pp. 41–45. [20] Princeton NLP Group, “mini-SWE-agent: Minimalist llm agent for software engineering,” https://github.com/SWE-agent/mini-swe-agent, 2025. [21] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “React: Synergizing reasoning and acting in language models,” in International Conference on Learning Representations (ICLR), 2023. [22] C. S. Xia and L. Zhang, “Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 819–831. [23] J. Sohn and S. Yoo, “FLUCCS: Using code and change metrics to improve fault localization,” in Proceedings of the 26th ACM SIGSOFT international symposium on software testing and analysis, 2017, pp. 273–283. [24] T. Xu, J. Zhang, P. Huang, J. Zheng, T. Sheng, D. Yuan, Y. Zhou, and S. Pasupathy, “Do not blame users for misconfigurations,” in Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles, 2013, pp. 244–259. [25] S. Zhang and M. D. Ernst, “Automated diagnosis of software configuration errors,” in 2013 35th International Conference on Software Engineering (ICSE). IEEE, 2013, pp. 312–321. [26] Y. Zhou, X. Hu, S. Xu, Y. Jia, Y. Liu, J. Wang, G. Xu, W. Wang, S. Liu, and T. Baker, “Multi-misconfiguration diagnosis via identifying correlated configuration parameters,” IEEE Transactions on Software Engineering, vol. 49, no. 10, pp. 4624–4638, 2023. [27] N. Saavedra and J. F. Ferreira, “Glitch: Automated polyglot security smell detection in infrastructure as code,” in Proceedings of the 37th IEEE/ACM international conference on automated software engineering, 2022, pp. 1–12. [28] C. S. Xia, Y. Wei, and L. Zhang, “Automated program repair in the era of large pre-trained language models,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2023, pp. 1482–1494. [29] J. A. Jones and M. J. Harrold, “Empirical evaluation of the tarantula automatic fault-localization technique,” in Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering, 2005, pp. 273–282. [30] X. Li, W. Li, Y. Zhang, and L. Zhang, “Deepfl: Integrating multiple fault diagnosis dimensions for deep fault localization,” in Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis, 2019, pp. 169–180. [31] S. Zhang, S. Xia, W. Fan, B. Shi, X. Xiong, Z. Zhong, M. Ma, Y. Sun, and D. Pei, “Failure diagnosis in microservice systems: A comprehensive survey and analysis,” ACM Transactions on Software Engineering and Methodology, 2025. [32] L. Zhang, T. Jia, M. Jia, Y. Wu, A. Liu, Y. Yang, Z. Wu, X. Hu, P. Yu, and Y. Li, “A survey of aiops in the era of large language models,” ACM Computing Surveys, 2025.

[33] P. Wang, J. Xu, M. Ma, W. Lin, D. Pan, Y. Wang, and P. Chen, “Cloudranger: Root cause identification for cloud native systems,” in 2018 18th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID). IEEE, 2018, pp. 492–502. [34] P. Liu, H. Xu, Q. Ouyang, R. Jiao, Z. Chen, S. Zhang, J. Yang, L. Mo, J. Zeng, W. Xue et al., “Unsupervised detection of microservice trace anomalies through service-level deep bayesian networks,” in 2020 IEEE 31st International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2020, pp. 48–58. [35] L. Pham, H. Ha, and H. Zhang, “Baro: Robust root cause analysis for microservices via multivariate bayesian online change point detection,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 2214–2237, 2024. [36] T. Xu, X. Jin, P. Huang, Y. Zhou, S. Lu, L. Jin, and S. Pasupathy, “Early detection of configuration errors to reduce failure damage,” in 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16), 2016, pp. 619–634. [37] M. Attariyan and J. Flinn, “Automating configuration troubleshooting with dynamic information flow analysis,” in 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI 10), 2010. [38] Q. Chen, T. Wang, O. Legunsen, S. Li, and T. Xu, “Understanding and discovering software configuration dependencies in cloud and datacenter systems,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2020, pp. 362–374. [39] T. Mahmud, O. R. Gatla, D. Zhang, C. Love, R. Bumann, and M. Zheng, “{ConfD}: Analyzing configuration dependencies of file systems for fun and profit,” in 21st USENIX Conference on File and Storage Technologies (FAST 23), 2023, pp. 199–214. [40] X. Lian, Y. Chen, R. Cheng, J. Huang, P. Thakkar, M. Zhang, and T. Xu, “Large language models as configuration validators.” in ICSE, 2025, pp. 1704–1716.

[41] J. Wen, Z. Chen, Z. Zhu, F. Sarro, Y. Liu, H. Ping, and S. Wang, “Llmbased misconfiguration detection for aws serverless computing,” ACM Transactions on Software Engineering and Methodology, vol. 35, no. 4, pp. 1–28, 2026. [42] Y. Chen, J. Pan, J. Clark, Y. Su, N. Zheutlin, B. Bhavya, R. R. Arora, Y. Deng, S. Jha, and T. Xu, “Stratus: A multi-agent system for autonomous reliability engineering of modern clouds,” Advances in Neural Information Processing Systems, vol. 38, pp. 50 119–50 165, 2026. [43] Y. Chen, M. Shetty, G. Somashekar, M. Ma, Y. Simmhan, J. Mace, C. Bansal, R. Wang, and S. Rajmohan, “AIOpsLab: A holistic framework to evaluate ai agents for enabling autonomous clouds,” Proceedings of Machine Learning and Systems, vol. 7, 2025. [44] PingCAP, “TiDB Operator Overview,” https://docs.pingcap.com/ tidb-in-kubernetes/stable/tidb-operator-overview, 2026. [45] DeepSeek-AI, “DeepSeek-V4-Pro Model Card,” https://huggingface.co/ deepseek-ai/DeepSeek-V4-Pro, 2026, accessed: 2026-06-10. [46] ——, “DeepSeek-V4-Flash Model Card,” https://huggingface.co/ deepseek-ai/DeepSeek-V4-Flash, 2026, accessed: 2026-06-10. [47] Anthropic, “Claude-Opus-4-8 Model Card,” https://www.anthropic.com/ news/claude-opus-4-8, 2026, accessed: 2026-06-10. [48] OpenAI, “GPT-5.1 Model Card,” https://developers.openai.com/api/docs/ models/gpt-5.1, 2026, accessed: 2026-06-10. [49] ——, “GPT-5 mini Model Card,” https://developers.openai.com/api/docs/ models/gpt-5-mini, 2026, accessed: 2026-06-10. [50] ——, “GPT-4o mini Model Card,” https://developers.openai.com/api/ docs/models/gpt-4o-mini, 2026, accessed: 2026-06-10. [51] Qwen Team, “Qwen3-Coder-30B-A3B-Instruct Model Card,” https:// huggingface.co/Qwen/Qwen3-Coder-30B-A3B-Instruct, 2026, accessed: 2026-06-10. [52] OpenTelemetry Project, “opentelemetry-demo issue #1468: frontend instrumentation-fs creates unnecessary span noise,” https://github.com/ open-telemetry/opentelemetry-demo/issues/1468, 2026.

Related documents

• Agentic Metaverse Services: A New As-a-Service Paradigm#414170
• DepRepair: LLM-Based Source-Code Repair for Dependency Breaking Changes#386947
• Optimal Repairs for Unary Functional Dependencies: Resolving the Case of Updates#615300
• Optimal Repairs for Unary Functional Dependencies: Resolving the Case of Updates#614333
• Optimal Repairs for Unary Functional Dependencies: Resolving the Case of Updates#459765