ErrorPrism: Reconstructing Error Paths

• ErrorPrism is an automated method that reconstructs multi-hop error propagation paths in cloud service systems by leveraging static analysis.
• It integrates code indexing with an LLM agent to iteratively trace log messages back to the original error source, ensuring high root-cause accuracy.
• The system demonstrates significant efficiency gains and precision improvements in production settings, outperforming traditional static and LLM-only baselines.

Searching arXiv for the specified paper and closely related context. I’ll look up the paper record on arXiv to ground the article. ErrorPrism is an automated method for reconstructing error propagation paths in production microservice systems, designed for root cause analysis in cloud service systems where failures exhibit cascading effects. It targets a traceability problem created by error wrapping, a practice in which errors are enriched with context at each layer of the function call stack, producing an error chain that describes a failure from its technical origin to its business impact. The system combines static analysis on service code repositories with an LLM agent that performs an iterative backward search from a final log message to its source, and it was evaluated on 67 production microservices at ByteDance (Pu et al., 30 Sep 2025).

1. Problem formulation and system scope

The formal input to ErrorPrism consists of an error log message $L$, represented as a flat string produced by a top-level logging call, and a microservice source-code repository $C$. From $C$, the method extracts the set of all functions $F$ in the codebase, a static directed function-call graph $G=(F,E)$ where $(f_i \to f_j)\in E$ iff $f_i$ contains a call site that may invoke $f_j$, and a mapping $\sigma:F \to 2^{S}$ from each function to the set $S$ of string constants it directly references. The desired output is an ordered sequence of functions

$C$0

such that $C$1 is the function whose logging statement printed $C$2, $C$3 is the originator that first created the low-level error, every $C$4 passed its error to $C$5 via an explicit call or an RPC/asynchronous boundary, and the layered wrapping of error strings in each $C$6 explains the fragments of $C$7 in reverse order (Pu et al., 30 Sep 2025).

The detailed formulation further states that, if call-depth-$C$8 closure $C$9 denotes the set of all constants reachable within $C$0 hops of calls from $C$1, then the target path can be viewed as maximizing a joint probability:

$C$2

In practice, however, ErrorPrism reconstructs a single valid path rather than searching this full probability space. This places the method between explicit graph search and probabilistic inference: the formulation is probabilistic, while the implementation is path-reconstructive.

The work is presented under the title “ErrorPrism: Reconstructing Error Propagation Paths in Cloud Service Systems,” while the detailed summary also refers to the system as “LogPrism.” The naming discrepancy is part of the provided record rather than a distinct methodology. A plausible implication is that the core contribution is stable across both names: automated reconstruction of multi-hop error chains in microservice codebases.

2. Static analysis and code indexing

ErrorPrism begins with a static analysis phase that constructs two central artifacts from the repository: a function-call graph and a string-constant index. For function-call graph construction, all Go source files are parsed into SSA and Rapid Type Analysis (RTA) is applied to conservatively resolve targets of indirect calls, including interfaces and virtual dispatch. The graph $C$3 is then built in $C$4 time, neglecting SSA and type-analysis cost (Pu et al., 30 Sep 2025).

String-constant extraction is defined through the mapping $C$5. In each function $C$6, the SSA is scanned for uses of errors.New and fmt.Errorf as error-creation APIs, and logger.Error and log.Printf as logging APIs. All literal string operands are collected into $C$7. The extracted constants are not limited to terminal log lines; they include error formats and log templates that may later appear as fragments of wrapped messages.

The method then computes a transitive closure of constants. For each function $C$8 and depth $C$9,

$F$0

In practice, $F$1 is used. The summary gives backward-BFS pseudo-code for each constant $F$2, starting from callers of $F$3 and propagating the reachability relation upward through caller edges. The result is a reverse index mapping every function $F$4 to the set of all string fragments it may indirectly contribute.

This static phase is important because the observed log $F$5 is only a flattened endpoint of a multi-layer wrapping process. By associating functions not only with their directly referenced strings but also with strings reachable through nearby callees, ErrorPrism creates a compact candidate space for subsequent reasoning. This suggests that the system treats string evidence as a structural proxy for latent propagation history.

3. Iterative backward search with an LLM agent

After static pruning, ErrorPrism employs a ReAct-style LLM agent to walk the call graph from the logging function $F$6 back toward the root-cause function $F$7. The starting function is identified either from the log’s metadata, such as file and line, or by matching the log template to $F$8. An initial BFS queue $F$9 is then constructed (Pu et al., 30 Sep 2025).

The iterative step proceeds as follows. The current function $G=(F,E)$0 is popped from the queue. The system invokes view_callee_closure(f_current) to obtain a list of callers $G=(F,E)$1 whose $G=(F,E)$2 contains string fragments in $G=(F,E)$3. If only one caller remains, it is selected as the next hop. Otherwise, the source of each candidate is retrieved through check_function_code(c_i). If ambiguity persists, fuzzy_search_in_closure(keyword) is used to bridge broken edges, including RPC endpoint names. The LLM is then prompted with the error $G=(F,E)$4, the candidate callers, and their code snippets, and is asked to decide which candidate is most likely to wrap the error next. The chosen caller $G=(F,E)$5 is appended to $G=(F,E)$6 and pushed into $G=(F,E)$7. The process terminates when $G=(F,E)$8 has no further callers or matches a known root-cause utility.

The selection step can be viewed as

$G=(F,E)$9

where the score is implicitly defined by the LLM’s log-probabilities over the most plausible path extension. The implementation therefore does not rely on a separately engineered symbolic ranking function. Instead, the LLM resolves residual ambiguity after static analysis has reduced the branching factor.

This hybrid decomposition reflects a specific division of labor. Static analysis provides conservative reachability and candidate scoping; the LLM contributes semantic reasoning over source code, string fragments, and wrapping logic. The summary explicitly characterizes this as a way to bridge the gap between purely static call-graph methods, described as fast but imprecise, and one-shot LLM approaches, described as semantic but unfocused.

4. Search-space reduction and computational significance

A central claim of ErrorPrism is that accurate path reconstruction depends on aggressive search-space reduction before LLM reasoning is invoked. Without static pruning, a naive backward traversal might consider all $(f_i \to f_j)\in E$0 callers at each hop, yielding an exponential blowup $(f_i \to f_j)\in E$1 for paths of length $(f_i \to f_j)\in E$2. ErrorPrism avoids this by restricting attention to callers whose transitive constant closures intersect the observed log fragments (Pu et al., 30 Sep 2025).

The evaluation summary reports that, across 67 services with approximately 25,000 functions total, candidate sets for each log template averaged approximately 8 functions, compared with more than 100 in the unpruned graph. It further reports that this 10–20$(f_i \to f_j)\in E$3 reduction in branching factor drives a 8.4$(f_i \to f_j)\in E$4 speedup and raises static precision to 90.7%. These numbers locate the main contribution less in novel language-model prompting than in the interaction between code indexing and iterative search.

The significance of this reduction is methodological as well as computational. The findings section states that a small, high-precision candidate set from static analysis is a necessary pre-condition for reliable LLM reasoning in large codebases. This suggests that ErrorPrism should not be understood as an end-to-end generative system operating directly over the entire repository. Rather, it is a constrained reasoning pipeline in which code-scale complexity is handled before semantic disambiguation.

A plausible implication is that the system’s performance depends on preserving this balance. If the candidate set grows too large, the LLM step approaches the unfocused behavior of a general repository-wide prompt; if pruning is too aggressive, legitimate propagation paths may be excluded. The supplied limitations on scope selection are consistent with this interpretation.

5. Experimental evaluation in production microservices

The experimental environment comprises 67 Go microservices at ByteDance totaling 988 kLOC. From 3 million raw error logs, Drain3 parsed 257 unique templates. Ground truth was established by manually pairing 102 templates with complete paths $(f_i \to f_j)\in E$5 of length 1–6 hops. The baselines were Pure Static Analysis, enhanced with pointer-analysis and invocation telemetry; Internal Code Agent, a general-purpose ReAct agent at ByteDance; CoReQA, described as one-shot RAG; and Pure LLM, defined as a single prompt with the entire codebase (Pu et al., 30 Sep 2025).

The reported metrics are Accuracy, defined as the percentage of templates where predicted $(f_i \to f_j)\in E$6 exactly matches ground truth; Static Precision, for the static-only baseline, defined as average $(f_i \to f_j)\in E$7; and Inference Time, defined as average seconds per template. The main results are as follows.

Method	hop=0 / 1 / 2 / 3 / $(f_i \to f_j)\in E$8	total
LogPrism	100 / 100 / 95.2 / 100 / 85.7	97.0
Static	100 / 90.4 / 98.8 / 72.9 / 66.1	90.7
Agent	100 / 87.1 / 90.5 / 84.6 / 57.1	87.1
CoReQA	75 / 67.7 / 54.8 / 53.8 / 14.3	57.4
PureLLM	100 / 64.5 / 45.2 / 30.8 / 0.0	50.5

For efficiency, the average inference time is reported as 5.93 s for LogPrism and 49.75 s for the Internal Agent. CoReQA and PureLLM use a single LLM call of approximately 8–12 s, with no long tail but low accuracy. The work therefore presents ErrorPrism as simultaneously accurate and operationally practical in production settings.

The hop-stratified results are particularly informative. ErrorPrism maintains 100 accuracy at hop 0, 1, and 3, achieves 95.2 at hop 2, and 85.7 at hop $(f_i \to f_j)\in E$9. The static baseline remains competitive on shorter chains but degrades more strongly at deeper hops. PureLLM degrades sharply with path depth and reaches 0.0 at hop $f_i$0. This pattern is consistent with the stated finding that hybrid design yields both high accuracy on deep, greater-than-3-hop chains and practical performance in production.

6. Findings, limitations, and prospective extensions

The key findings reported for ErrorPrism are threefold. First, a small, high-precision candidate set from static analysis is described as a necessary pre-condition for reliable LLM reasoning in large codebases. Second, the LLM’s semantic reasoning resolves residual ambiguity, boosting end-to-end accuracy from 90.7% for static only to 97.0%. Third, the hybrid design yields both high accuracy on deep greater-than-3-hop chains and practical performance in production (Pu et al., 30 Sep 2025).

The limitations are also explicit. The system is tailored to Go’s error-as-value idiom, and exception-based languages such as Java and Python will require re-engineering of the static phase. Log-templating errors from Drain mis-grouping account for approximately 3% of failures. Scope selection is identified as a further limitation: too many repositories hurt efficiency, while too few miss paths. These caveats narrow the conditions under which the reported results should be generalized.

The summary lists several potential improvements. One is to extend the static phase with lightweight flow-sensitivity to prune further. Another is to integrate dynamic traces, when available, to cover rare RPC patterns. A third is to apply the method to exception languages via stack-unwinding and throw/catch analysis. A fourth is to enhance log parsing with LLM-guided clustering, with Lilac named as a relevant direction, to reduce templating noise.

These prospective extensions indicate that ErrorPrism is not limited to a single heuristic pipeline but defines a broader reconstruction paradigm: static graph-based narrowing, string-fragment reachability, and LLM-guided backward path selection. The published results support the narrower claim that, in Go microservice systems with pervasive error wrapping, this paradigm can reconstruct complete multi-hop error paths with 97.0% accuracy on the reported ByteDance evaluation.