Method and apparatus for repairing application code

Abstract

This specification provides an application code repair method and apparatus. The method includes: monitoring the execution status of a target application in multiple stages; when a failure is detected in a certain stage, capturing error logs and runtime environment status, and generating structured fault data containing fault stage identifiers and standardized error characteristics; based on the structured fault data, obtaining code change records before the fault occurred and dependency information between project resources; using the code change records to determine the set of resources that have recently changed, and combining the dependency information, filtering out a set of candidate resources from all project resources that have direct or indirect dependency relationships with the root cause of the fault; extracting the resource content from the candidate resource set to construct a repair context, sending a request containing the repair context to a code repair model, and receiving the candidate patch returned by the model, wherein the candidate patch contains code change instructions to be executed.

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to the field of software engineering, and in particular, to a method and apparatus for repairing application code. BACKGROUND

[0002] In the process of software development and maintenance, the automatic repair of application code is a key technical means to improve development efficiency and ensure system stability. With the wide application of large language models (LLM) in the field of code generation, code repair solutions based on artificial intelligence have gradually become mainstream. Such solutions usually capture error logs during application runtime as prompts and input them into a code repair model to generate corresponding patch code to repair faults.

[0003] In existing code repair practices, constructing a repair context is crucial. To help the model understand the context in which the fault occurs, existing technologies usually adopt two strategies: one is to point directly to the files and a small number of adjacent files as the context; the second is to package a large amount of source code, configuration files, and even part of the dependency library information in the project to send to the model in order to cover all possible fault causes.

[0004] However, the above existing technologies often have difficulty in balancing the integrity and precision of the context when dealing with fault repair of complex applications. Applications usually have a large code size and complex dependency relationships. If only the directly related files are extracted, it is easy to miss the real fault cause due to limited vision; on the contrary, if a wide range of code resources are introduced, the context will be filled with a large amount of noise data unrelated to the current fault logic. Such redundant context information not only significantly increases the reasoning computation burden of the model, but more importantly, too much irrelevant code will distract the model's attention and interfere with its judgment of the core fault logic.

[0005] Therefore, it is necessary to provide an improved solution to accurately define the context range required for repair, thereby improving the repair accuracy. SUMMARY

[0006] One or more embodiments of the present specification describe a method and apparatus for repairing application code, which can accurately define the context range required for repair, thereby improving the repair accuracy.

[0007] In a first aspect, a method for repairing application code is provided, comprising:

[0008] The execution state of a target application in a multi-stage running chain is monitored, and when it is detected that a stage fails to execute, error logs and running environment states are captured, and structured failure data containing failure stage identification and normalized error features is generated;

[0009] Based on the structured failure data, code change records before the failure and dependency relationship information between project resources are obtained;

[0010] Using the code change records, a set of resources that have recently changed is determined, and in combination with the dependency relationship information, a candidate resource set that has a direct or indirect dependency relationship with the root cause of the failure is screened from the full set of project resources;

[0011] The content of the candidate resource set is extracted to construct a repair context, a request containing the repair context is sent to a code repair model, and a candidate patch returned by the code repair model is received, the candidate patch containing code change instructions to be executed.

[0012] In a possible implementation, the normalized error features include a failure signature, deterministic failure feature information, and a running time input state summary;

[0013] The structured failure data containing the failure stage identification and the normalized error features is generated, including:

[0014] The error logs are cleaned to remove non-deterministic information and retain deterministic failure feature information, the deterministic failure feature information including error codes, key stack frames, and module identifications;

[0015] A running time input state summary before the failure is calculated, the running time input state summary being generated based on code file hash values, dependency lock file hash values, environment configuration information, and execution commands involved in the running stage;

[0016] Based on the deterministic failure feature information and the running time input state summary, a failure signature with uniqueness is generated;

[0017] The failure stage identification, the failure signature, the deterministic failure feature information, and the running time input state summary are encapsulated to form the structured failure data.

[0018] In a possible implementation, the candidate resource set that has a direct or indirect dependency relationship with the root cause of the failure is screened from the full set of project resources, including:

[0019] An initial root resource set is determined, the initial root resource set including files directly pointed to by error logs, resources associated with structured errors, and configuration files necessary for the current failure stage;

[0020] Obtaining a set of modified resources in the current run before the fault occurs by using the code change record;

[0021] Based on the project resource dependency graph, recursively searching for resources having import, reference, containing or generation relationship with the set of modified resources from the initial root resource set until reaching a preset depth threshold or confidence threshold, to form the candidate resource set.

[0022] Further, the project resource dependency graph describes at least one of the following dependency relationships:

[0023] Code import or reference relationship between source code files;

[0024] Call or version constraint relationship between source code files and third-party dependent packages;

[0025] Reference relationship of configuration files to resource files, routing rules or build targets;

[0026] Build generation relationship of the build tool generating output files according to input files.

[0027] In a possible implementation, the method further includes:

[0028] Traversing each resource in the candidate resource set to determine whether it meets a writable condition; the writable condition includes that the resource has a creation, modification or deletion record in the code change record of the current run; or the resource belongs to a necessary repair root specified by the current fault stage strategy and can provide corresponding stage input evidence; wherein the necessary repair root includes a dependency manifest file, a lock file or a routing configuration file;

[0029] If the result of the determination is that the resource meets the writable condition, the resource is marked as a writable resource and added to a writable resource subset;

[0030] If the result of the determination is that the resource does not meet the writable condition, the resource is marked as a read-only resource.

[0031] In a possible implementation, the candidate resource set is divided into a writable resource subset that is allowed to be modified, and the method further includes:

[0032] Verifying whether resources to be modified by the candidate patch all belong to the writable resource subset;

[0033] If the verification passes, the candidate patch is merged into the code base of the target application under a preset condition.

[0034] Further, the verification whether resources to be modified by the candidate patch all belong to the writable resource subset includes:

[0035] parsing the candidate patch to extract a write set declared therein, the write set containing resource identities to be added, modified or deleted;

[0036] comparing the write set with the writable resource subset;

[0037] if the write set is a subset of the writable resource subset, the verification passes;

[0038] if there is a resource in the write set that does not belong to the writable resource subset, the verification fails, and the candidate patch is rejected.

[0039] Further, the incorporating the candidate patch into the code base of the target application under the preset condition comprises:

[0040] based on the code baseline and the environment snapshot before the fault occurs, creating two isolated execution environments, namely, a control environment without applying the patch and a processing environment applying the candidate patch;

[0041] performing the same verification process in the control environment and the processing environment, if it is detected that the control environment reproduces the fault corresponding to the structured fault data, and the processing environment eliminates the fault and meets the preset acceptance condition, generating a verification credential containing the fault feature, the patch content and the verification result;

[0042] when the state of the current active code base is consistent with the baseline state bound to the verification credential, incorporating the candidate patch into the code base of the target application according to the verification credential.

[0043] Further, the acceptance condition comprises:

[0044] the baseline version of the current active workspace is consistent with the baseline version when the structured fault data is generated;

[0045] the hash values of each resource in the candidate resource set in the current active workspace are consistent with the state digest before the fault occurs.

[0046] In one possible implementation, further comprising:

[0047] maintaining a history record table to record the fault signatures of the processed structured fault data;

[0048] before constructing the repair context, querying the history record table whether there is a same fault signature as the current fault;

[0049] if there is a same fault signature, stopping the repair process of the current fault.

[0050] In a second aspect, a repair device for application code is provided, comprising:

[0051] The generation unit is used to monitor the execution status of the target application in a multi-stage execution chain. When a failure is detected in a certain stage, it captures error logs and runtime environment status, and generates structured fault data containing fault stage identifiers and standardized error characteristics.

[0052] The acquisition unit is used to acquire code change records and dependency information between project resources before the fault occurred, based on the structured fault data generated by the generation unit.

[0053] The filtering unit is used to determine the set of resources that have recently changed by using the code change records obtained by the acquisition unit, and to filter out the set of candidate resources that have a direct or indirect dependency relationship with the root cause of the failure from the full set of project resources in combination with the dependency relationship information obtained by the acquisition unit.

[0054] The repair unit is used to extract resource content from the candidate resource set obtained by the filtering unit to construct a repair context, send a request containing the repair context to the code repair model, and receive candidate patches returned by the code repair model, wherein the candidate patches contain code change instructions to be executed.

[0055] Thirdly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of the first aspect.

[0056] Fourthly, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method of the first aspect.

[0057] By using the methods and apparatus provided in the embodiments of this specification, and by capturing the fault state in a multi-stage operation chain and generating structured fault data, and combining code change records with project resource dependencies, a set of candidate resources that are directly or indirectly related to the root cause of the fault can be accurately screened from all resources. This refined screening mechanism based on causal dependency analysis effectively eliminates a large amount of code noise that is unrelated to the fault, and can accurately define the context range required for repair, thereby improving the repair accuracy. Attached Figure Description

[0058] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification;

[0060] Figure 2 A flowchart illustrating a method for repairing application code according to one embodiment is shown;

[0061] Figure 3 A flowchart illustrating a method for filtering a set of candidate resources according to one embodiment is shown;

[0062] Figure 4 A flowchart of a fault signature-based deduplication method according to one embodiment is shown;

[0063] Figure 5 A schematic diagram illustrating the principle of constructing causal slices based on a dependency graph according to one embodiment is shown.

[0064] Figure 6 A timing flowchart illustrating a dual-environment counterfactual verification according to one embodiment is shown;

[0065] Figure 7 A schematic block diagram of an application code repair device according to one embodiment is shown. Detailed Implementation

[0066] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0067] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification. This implementation scenario involves the repair of application code; specifically, the repair is performed using a code repair model. (Refer to...) Figure 1 In the continuous delivery and operation system of software engineering, target applications typically undergo multiple discrete yet ordered operational phases, including compilation and building, static analysis, automated testing, and service operation. Anomalies in any of these phases can lead to delivery interruptions or service failures. With the evolution of artificial intelligence (AI) technology, AI-generated code agents have been introduced into the field of code repair, serving as an automated bridge connecting fault diagnosis and code correction. This agent uses a code repair model as its core inference engine, capable of understanding error characteristics described in natural language and the context of programming languages, and automatically generating code change instructions that conform to grammatical specifications and project constraints based on structured input. In this context, code generation for target applications is no longer limited to development from scratch, but extends to the accurate identification and automated correction of existing code defects. This involves parsing fault scene information, constructing a constrained repair context, and calling the model to infer candidate patches, which are then applied to the codebase after security verification, thus achieving a closed-loop process from fault perception to code self-healing. This process demonstrates the deep integration of artificial intelligence in software engineering and provides a new technical path for improving system stability and development efficiency.

[0068] In this embodiment, the system encapsulates the constructed repair context into a repair request and sends it to the code repair model. The code repair model can be an LLM fine-tuned from a large-scale code corpus, or a neural network model specifically trained for code debugging tasks. Its core capabilities include understanding error characteristics described in natural language and programming language code, and generating code change instructions that conform to syntax rules. Optionally, the repair request not only includes the aforementioned repair context but also explicitly includes permission constraint metadata. This metadata clearly indicates the specific file paths or identifiers of the writable resource subset, informing the model that when generating patches, modification suggestions are only allowed for files in the writable resource subset; for read-only resources, only their contents can be read to aid in reasoning. After receiving the repair request, the code repair model's attention mechanism focuses on a set of low-noise, highly correlated candidate resources and performs causal reasoning based on the error characteristics in the structured fault data, ultimately generating candidate patches.

[0069] Candidate patches are sets of structured or unstructured code change instructions output by the code fix model. They can take the form of a standard uniform diff format file or a structured JSON object containing the target file path, starting line number, deleted code blocks, and added code blocks.

[0070] Once a candidate patch is received and passes verification, it will be used to fix the application code. The specific application process typically involves the system locating the file and line number in the target application codebase that matches the candidate patch, replacing the original deleted code block with the newly added code block from the patch, or inserting the new code into a specified location, thereby completing the logical correction of the faulty code. Before being officially merged into the main branch, the fixed code is usually placed in an isolated environment for further automated verification (such as re-executing unit tests or replaying interfaces) to confirm that the fault has been completely eliminated and no new regression issues have been introduced.

[0071] Figure 2 This diagram illustrates a method flowchart for repairing application code according to one embodiment, which can be based on... Figure 1 The implementation scenario is shown. For example... Figure 2As shown, the application code repair method in this embodiment includes the following steps: Step 21, monitor the execution status of the target application in a multi-stage execution chain. When a stage failure is detected, capture error logs and runtime environment status to generate structured fault data containing fault stage identifiers and standardized error characteristics; Step 22, based on the structured fault data, obtain code change records before the fault occurred and dependency information between project resources; Step 23, use the code change records to determine the set of resources that have recently undergone changes, and combine the dependency information to filter out a set of candidate resources from all project resources that have direct or indirect dependency relationships with the root cause of the fault; Step 24, extract the resource content from the candidate resource set to construct a repair context, send a request containing the repair context to the code repair model, and receive the candidate patch returned by the code repair model, wherein the candidate patch contains code change instructions to be executed. The specific execution methods of each of the above steps are described below.

[0072] First, in step 21, the execution status of the target application in the multi-stage runtime chain is monitored. When a failure is detected in a certain stage, error logs and runtime environment status are captured, generating structured fault data containing fault stage identifiers and standardized error characteristics. It can be understood that the multi-stage runtime chain refers to the discrete logical steps or processing stages executed sequentially according to a preset order throughout the complete lifecycle of the target application, from code construction to service deployment. Specifically, it covers key nodes such as dependency installation, code compilation and type checking, static code analysis, unit test execution, integration test verification, and service startup and runtime request processing. Each runtime stage has clear task boundaries, an independent execution environment, and specific input / output specifications.

[0073] When an unexpected result is detected at a certain stage (e.g., compilation error, test case failure, or abnormal service response), a fault capture mechanism can be immediately triggered to synchronously obtain the error log and runtime environment status at that moment. The error log records information such as the exception stack, error code, and module identifier during program execution, while the runtime environment status includes contextual information such as operating system version, container configuration, environment variables, and resource usage.

[0074] In one example, the normalized error features include a fault signature, deterministic fault feature information, and a runtime input state summary;

[0075] The generation of structured fault data, which includes fault stage identifiers and standardized error features, includes:

[0076] The error log is cleaned to remove nondeterministic information and retain deterministic fault characteristic information, including error codes, key stack frames, and module identifiers.

[0077] Calculate a runtime input state summary before the failure occurs, which is generated based on the hash values ​​of code files involved in the runtime phase, the hash values ​​of dependency lock files, environment configuration information, and executed commands.

[0078] Based on the deterministic fault feature information and the runtime input state summary, a unique fault signature is generated;

[0079] The fault stage identifier, the fault signature, the deterministic fault feature information, and the runtime input state summary are encapsulated to form the structured fault data.

[0080] In this example, the original error logs are denoised and cleaned while retaining stable deterministic fault characteristics. At the same time, an accurate runtime input state summary is generated based on code, dependencies, and environment configuration, effectively eliminating the interference of non-deterministic factors such as timestamps and process IDs on fault analysis. The unique fault signature generated on this basis, combined with the normalized error features, not only achieves unique identification and fast retrieval of faults, but also provides a stable and reliable contextual anchor for subsequent causal analysis, ensuring that structured fault data can accurately characterize the essence of the fault.

[0081] Then, in step 22, based on the structured fault data, the code change records and dependency information between project resources prior to the fault are obtained. It can be understood that the code change records refer to the set of all resources modified and their change details extracted from the version control system from the previous successful baseline to the time of the fault, including newly added, modified, or deleted file paths, line-level differences, and commit metadata. Their purpose is to identify potential sources of risk from recent human-introduced changes. The project resource dependency information is a topological graph describing the call, reference, inclusion, or generation relationships between all project resources, constructed through static analysis methods such as parsing project build configurations, source code import statements, configuration file references, and build tool rules. Its purpose is to depict the implicit association links between code and configuration.

[0082] The embodiments in this specification do not query these two types of information in isolation, but rather semantically align them with the fault stage identifiers and standardized error features in the structured fault data to ensure that the obtained code change records and dependencies are limited to the specific operational stage and logical scope of the current fault occurrence.

[0083] Next, in step 23, the set of resources that have recently undergone changes is determined using the code change records, and combined with the dependency information, a set of candidate resources that have a direct or indirect dependency relationship with the root cause of the failure is selected from all project resources. It can be understood that in step 23, the system performs core causal dependency analysis and refined resource filtering operations.

[0084] In one embodiment, the process of selecting a set of candidate resources from the full range of project resources that have a direct or indirect dependency on the root cause of the failure is not a simple static link search, but a causal root cause analysis process based on multi-source evidence fusion. Figure 3 The flowchart illustrates a method for filtering a candidate resource set according to one embodiment, specifically including the following steps:

[0085] Step 31: Construct the causal hypothesis space.

[0086] The system defines the "direct file pointed to by the error log" as an explicit fault anchor and the "resources modified in this round of operation" as an implicit change suspect set. The system first calculates the shortest path distance between the explicit fault anchor and the implicit change suspect set in the dependency graph. If the two are directly connected or connected through intermediate nodes with fewer than N hops (e.g., 3 hops), then all nodes on that path are marked as "high-confidence causal chains".

[0087] Step 32, introduce runtime state weighting.

[0088] To distinguish noise in static dependencies, the system introduces runtime input state summaries as weighting factors. For each resource node in the causal chain, the system checks whether its runtime hash value changed before the failure occurred, or whether its corresponding configuration item appeared in the parameters of the current execution command. If a resource is on the dependency path, but its runtime state is completely consistent with the baseline and has not been touched by the current execution command, its causal contribution weight is reduced; conversely, if its state summary shows abnormal fluctuations or is highly correlated with error characteristics, its weight is increased.

[0089] Step 33: Dynamic pruning and confidence convergence.

[0090] The system sets an initial confidence threshold θ. Starting from the explicit fault anchor point, it traverses backward along the dependency edges, accumulating the causal contribution weights of each node on the path. When the accumulated weight exceeds θ, the expansion of that branch stops; when the traversal depth reaches the preset maximum depth Dmax but the weight still does not meet the threshold, forced pruning is performed. All the nodes ultimately retained constitute the minimum candidate resource set.

[0091] By combining static dependency topology with dynamic runtime state, this solution can eliminate "dead code" or "irrelevant dependencies" that are related in code structure but are not executed in the current failure scenario, thereby greatly improving the purity of the candidate set and providing high-precision context focusing for subsequent model repair.

[0092] In one example, the step of filtering a set of candidate resources from the entire project resources that have a direct or indirect dependency relationship with the root cause of the failure includes:

[0093] Determine the initial root resource set, which includes the file directly pointed to by the error log, resources associated with structured errors, and configuration files necessary for the current fault stage;

[0094] Using the code change record, obtain the set of resources that were modified in the current run before the failure occurred;

[0095] Based on the project resource dependency graph, starting from the initial root resource set, resources that have import, reference, contain, or generate relationships with the modified resource set are recursively searched until a preset depth threshold or confidence threshold is reached, thus forming the candidate resource set.

[0096] In this example, an initial set of root resources is constructed using error log pointing to files, structured error-related resources, and necessary configuration files. Combined with code change records, recently changed resources are identified as potential fault initiation points. Then, a controlled recursive expansion search is performed based on the project's resource dependency graph. This achieves the precise extraction of a set of candidate resources from the entire project that only have a causal link with the root cause of the fault. This multi-dimensional filtering mechanism, based on "explicit error anchors + implicit change clues + dependency topology expansion," avoids the risk of missing root causes due to relying solely on stack trace information and effectively eliminates a large amount of irrelevant code noise. While ensuring the integrity of the fault context, it significantly reduces the interference and computational load of subsequent model inference, laying a reliable data foundation for high-precision repair.

[0097] Furthermore, the project resource dependency graph describes at least one of the following dependencies:

[0098] Code import or reference relationships between source code files;

[0099] The calling or version constraints between source code files and third-party dependency packages;

[0100] The configuration file contains references to resource files, routing rules, or build targets;

[0101] The build tool generates output files based on the input files, representing a build relationship.

[0102] In this example, by constructing a multi-dimensional project resource dependency graph that covers code import references, third-party dependency calls and version constraints, configuration file resource associations, and build tool generation relationships, it breaks through the limitations of traditional static analysis that only focuses on source code level calls, and achieves a complete characterization of the implicit relationships across the entire application chain. This fine-grained dependency description not only ensures that the root cause of the failure is not missed in complex scenarios such as cross-module, cross-configuration, and build artifacts, but also provides an accurate topological traversal basis for subsequent recursive screening, enabling the candidate resource set to truly reflect the failure propagation path, thereby significantly improving the comprehensiveness and accuracy of context construction.

[0103] In one embodiment, in order to construct a high-precision project resource dependency graph and achieve efficient recursive lookup, the system executes the following dependency graph construction and traversal strategy.

[0104] First, regarding the extraction and graphing of multi-dimensional dependencies: The system uses static code analysis tools to parse source code files and extract reference statements. For each reference statement, the system establishes a directed edge in the dependency graph from the current source file node to the referenced file node, with the edge attribute labeled "Source Code Import". If the referenced file belongs to a third-party library, its package name and version number are further parsed to establish a call edge from the source file to the third-party dependency package. The system parses the project's build configuration file. For example, it obtains the version constraints of third-party dependencies and maps them to attribute nodes or edge weights in the dependency graph; it parses plugin configurations and resource copying rules, identifies the generation relationship between input and output files, and establishes a "Build Generation" directed edge from the source file to the build artifact in the graph. Explicit generation dependency chains are established between files. The system parses the configuration file to identify references to resource file paths, routing rules, or environment variable keys. For example, it establishes implicit reference edges from configuration file nodes to related processing logic code nodes or external service nodes.

[0105] Secondly, regarding the recursive search strategy based on dynamic thresholds: When recursively searching from the initial root resource set based on the aforementioned dependency graph to form a candidate resource set, the system employs a dynamically adjusted depth threshold and confidence threshold strategy to balance recall and precision. The system pre-calculates or calculates in real-time the call frequency of each dependency edge (e.g., the number of references obtained through historical runtime logs or static analysis). For paths with a reference count exceeding the preset high-frequency threshold (such as core utility classes and basic exception handling modules), the system automatically relaxes the recursion depth limit (e.g., expanding the default depth from 3 to 5 levels) to ensure that indirect fault propagation caused by deep nested calls is not missed. For paths with low call frequency or those in peripheral modules, the system raises the confidence threshold. Specifically, a resource on a path is included in the candidate set only if it simultaneously meets one of the following conditions: the resource was directly modified in the most recent code change record; there are multiple independent dependency links between the resource and the initial root resource (i.e., there is evidence of redundant dependency); the semantic similarity of the resource (calculated through vector embedding) highly matches the keywords in the error log. If the above enhancement conditions are not met, even if it is reachable in the dependency graph, it will be pruned and excluded due to insufficient confidence.

[0106] By meticulously constructing a full-link dependency graph covering source code, construction, and configuration, and combining it with a dynamic threshold strategy for intelligent pruning, the introduction of irrelevant noise resources can be significantly reduced while ensuring that no root cause of the fault is missed. This results in a final set of candidate resources that possesses both causal integrity and maintains an extremely high signal-to-noise ratio, thereby significantly improving the inference efficiency and accuracy of subsequent code repair models.

[0107] In one example, it also includes:

[0108] Traverse each resource in the candidate resource set and determine whether it meets the writable condition; the writable condition includes that the resource has a creation, modification or deletion record in the code change record of this run; or, the resource belongs to the necessary repair root specified by the current fault phase strategy and can provide corresponding phase input evidence; wherein, the necessary repair root includes dependency manifest file, lock file or route configuration file;

[0109] If the determination result is that the resource meets the writable condition, then mark it as a writable resource and add it to the writable resource subset;

[0110] If the determination result is that the resource does not meet the writable condition, then it is marked as a read-only resource.

[0111] In this example, by traversing the candidate resource set and judging the writability conditions based on the necessary repair roots (such as dependency lists, lock files, and routing configuration files) specified by the code change record or fault phase strategy, a fine-grained dynamic division of repair permissions is achieved. This mechanism, based on dual verification of change facts and policy rules, ensures that recently modified code and critical configurations that truly need adjustment are accurately included in the writable scope, while strictly marking unmodified base libraries, third-party dependencies, and other resources used only as inference references as read-only. This ensures that the model can correct real fault points while effectively preventing it from overstepping its boundaries to modify core infrastructure or irrelevant modules, significantly improving the security and controllability of automatic repair operations.

[0112] In one embodiment, determining whether a resource meets the writable condition is performed dynamically by a built-in policy engine. This policy engine contains the following rule hierarchy:

[0113] Change priority rule: Any resource with a creation, modification, or deletion record in the current code change log is marked as "high priority writable" by default. This is based on the statistical assumption that "recent changes are the main source of failures."

[0114] Necessary Fix Root Exception Rule: For resources not appearing in the change log, if they belong to a predefined "necessary fix root" category (such as the dependency manifest file pom.xml, the lock file package-lock.json, or the routing configuration file routes.yaml), the system further checks whether it can provide "stage input evidence." For example, if the error log indicates "ClassNotFound" and the missing class belongs to a newly introduced dependency package, the system parses the dependency manifest file to confirm whether it declares the dependency. If the declaration exists but there is a version conflict, the dependency manifest file is marked as "conditionally writable," allowing the model to adjust the version number or exclude conflicting items.

[0115] Read-only protection rule: Except as described above, all third-party library source code, compiled binary files, and core infrastructure configuration files (such as database underlying driver configurations) are forcibly marked as "read-only". If the model attempts to modify read-only resources when generating a patch, the generated change instructions will be automatically filtered out in subsequent verification steps or will cause verification to fail.

[0116] Through the layered strategy engine, the system ensures both open modification permissions for the most likely sources of failure (modified code) and controlled modification capabilities for critical configuration files, while strictly blocking immutable areas, thus achieving a balance between the freedom to repair and the security boundaries.

[0117] Finally, in step 24, the system extracts resource content from the candidate resource set to construct a repair context, sends a request containing the repair context to the code repair model, and receives candidate patches returned by the code repair model. These candidate patches contain code change instructions to be executed. It can be understood that in step 24, the system performs the assembly of the repair context, model interaction, and patch retrieval operations.

[0118] In this embodiment, the contents of all resources (including writable resource subsets and read-only resources) in the candidate resource set selected in step 23 are first extracted, serialized, and encapsulated, and then combined with structured fault data to construct a repair context. This repair context serves as the input to the code repair model, containing complete causal link information supporting fault diagnosis and clearly defining the modification boundaries of resources through permission tags. Subsequently, the system encapsulates the repair context into a repair request and sends it to the code repair model, explicitly injecting constraint metadata of the writable resource subset into the request to guide the model to generate change instructions only for resources that are allowed to be modified during the inference process. After performing causal inference based on the low-noise, highly correlated repair context, the code repair model returns a candidate patch containing the code change instructions to be executed. This candidate patch typically adopts a unified difference format or a structured JSON object, clearly identifying the target file path, modified line number, and the content of the added or deleted code block, providing a directly applicable repair solution for subsequent security verification and code merging.

[0119] Optionally, the repair context includes not only the source code text content of each resource in the candidate resource set, but also explicitly embeds deterministic fault feature information, runtime input state summary, and permission tag metadata of writable resource subsets from the structured fault data; wherein, the permission tag metadata is appended to the corresponding resource path in the form of a tag or annotation, and is used to dynamically constrain its attention distribution and modification range during the model inference stage.

[0120] In one example, the candidate resource set is further divided into a writable subset that is allowed to be modified, and includes:

[0121] Verify whether all resources to be modified by the candidate patches belong to the writable resource subset;

[0122] If the verification passes, the candidate patch will be merged into the target application's codebase under preset conditions.

[0123] In this example, by adding a boundary verification mechanism for a subset of writable resources before merging the patch, the modification scope of the candidate patch generated by the model is strictly compared with the preset permission constraints. This effectively prevents the code repair model from modifying read-only resources, core basic libraries, and irrelevant configurations beyond the boundaries due to context interference or inference bias. This safety fallback strategy ensures that the automatic repair operation is always limited to a controllable range, avoiding system stability risks caused by accidental modifications, thereby significantly improving the security and engineering reliability of the automated code repair process.

[0124] Furthermore, the step of verifying whether all resources to be modified by the candidate patch belong to the writable resource subset includes:

[0125] The candidate patch is parsed, and the write set declared therein is extracted. The write set contains the resource identifiers to be added, modified or deleted.

[0126] Compare the write set with the writable resource subset;

[0127] If the write set is a subset of the writable resource subset, then the verification passes;

[0128] If there are resources in the write set that do not belong to the writable resource subset, the verification fails and the candidate patch is rejected.

[0129] In this example, by parsing candidate patches to extract resource identifiers for proposed additions, modifications, or deletions to form a write set, and then strictly comparing this set with a subset of writable resources, the automation and precision of repair permission verification are achieved. This determination mechanism based on set inclusion relationships can not only quickly identify out-of-bounds modification behavior and immediately intercept non-compliant patches, but also avoid the subjectivity and lag of manual review. It ensures that only code changes that fully comply with preset boundary constraints can enter the subsequent merging process, thereby providing a deterministic security barrier for the application codebase while ensuring repair efficiency.

[0130] Optionally, after the candidate patch passes verification, it will be applied to the target application codebase. The system locates the target file and line number declared in the patch, replaces the original deleted code block with the new code block, or inserts it at the specified location; the repaired code then enters the isolation verification environment and executes the same test cases in parallel with the unrepaired version to confirm that the fault has been eliminated and there are no regression issues.

[0131] Furthermore, the step of merging the candidate patch into the target application's codebase under preset conditions includes:

[0132] Based on the code baseline and environment snapshot before the failure, two isolated execution environments are created: a control environment without the patch applied and a processing environment with the candidate patch applied.

[0133] The same verification process is performed in the control environment and the processing environment. If the control environment reproduces the fault corresponding to the structured fault data, and the processing environment eliminates the fault and meets the preset acceptance conditions, a verification certificate containing fault characteristics, patch content and verification results is generated.

[0134] When the current active codebase state matches the baseline state bound to the verification credential, the candidate patch is merged into the target application's codebase based on the verification credential.

[0135] In this example, by constructing an isolated dual-environment verification mechanism based on the pre-fault baseline and an environment snapshot, the same verification process is executed in both the control and processing environments, and verification credentials bound to the baseline state are generated. This achieves automated counterfactual verification and state consistency check before candidate patches are merged. This safeguard strategy not only ensures that patches are only allowed to be merged when the fault is actually eliminated and the acceptance conditions are met, but also effectively prevents the risk of repair misalignment or conflict caused by concurrent changes to the codebase during this period. Thus, while ensuring the accuracy of the repair, it significantly improves the security and reliability of automated merging operations.

[0136] In one embodiment, to ensure environmental consistency for fault reproduction and repair verification, an "environment fingerprint" mechanism is introduced. The environment fingerprint refers to a digital digest that uniquely represents the runtime environment state of a target application at a specific time. Its generation process includes: static configuration hashing, extracting the operating system version, kernel parameters, container image ID, environment variable key-value pairs, and the contents of key configuration files, and calculating their hash values; dynamic dependency snapshots, capturing the current runtime dependency library version tree, and calculating the Merkle root hash of its overall structure; and hardware and resource feature encoding, recording CPU architecture identifiers, available memory thresholds, and disk mount point information, serializing them into standard JSON format, and participating in the hash calculation.

[0137] The three hash values ​​are concatenated and hashed again to obtain the final environment fingerprint. In the dual-environment verification step, the system not only compares the code baseline but also rigorously compares the environment fingerprints of the control environment and the processing environment. If the two environment fingerprints are inconsistent (e.g., slight differences in dependency package versions or different environment variables), the verification is deemed invalid, thus avoiding false positives or false negatives caused by "environment drift." This mechanism ensures that the repair operation is performed in a fully controllable and reproducible sandbox environment.

[0138] Furthermore, the same verification process is performed in both the control and processing environments to verify the causal validity of the patch through counterfactual reasoning. The specific execution logic is as follows:

[0139] Deterministic replay mechanism: In both the control environment (unpatched) and the processing environment (patched), the system initializes the random number generator with the exact same seed and injects the same input parameters corresponding to the runtime input state summary from the same structured fault data. This ensures that the execution trajectories of the two environments are completely consistent before encountering branch differences, eliminating the interference of nondeterministic factors on the verification results.

[0140] Difference capture and attribution analysis: The system acquires execution logs, memory snapshots, and output results from two environments in parallel.

[0141] Fault reproduction confirmation: If the specific error code or stack characteristics described in the structured fault data are not reproduced in the comparison with the environment, it is determined that the current environment state does not match the fault, the verification terminates, and an "environment inconsistency" error is returned.

[0142] Verification of repair effectiveness: If the fault is reproduced in the control environment, and the processing environment does not throw an exception at the same execution point, and the subsequent execution path deviates from the faulty branch and enters a normal termination state, then the patch is considered effective.

[0143] Side effect detection: The system compares the resource usage, global variable state, and external service call sequence of the two environments upon exit. If the processing environment introduces new exceptions, deadlocks, or unexpected resource leaks, the verification is considered to have failed even if the primary fault is eliminated.

[0144] Verification credential generation: The system generates a verification credential containing the fault feature hash, patch hash, environment fingerprint, and difference log summary only when three conditions are met: "fault reproduction in the control environment," "fault elimination in the treatment environment," and "no significant negative side effects." This credential serves as the sole trusted basis for patch merging, ensuring the traceability and security of automated remediation.

[0145] Furthermore, the acceptance criteria include:

[0146] The baseline version of the current active workspace is consistent with the baseline version used when the structured fault data was generated;

[0147] The hash values ​​of each resource in the candidate resource set in the current active workspace are consistent with the state summary before the failure occurred.

[0148] In this example, by rigorously comparing the baseline version of the current active workspace and the hash values ​​of each resource in the candidate resource set with the state summary at the time of the failure, as a prerequisite for patch merging, the consistency of the code and environment context on which the repair verification depends is effectively ensured in the time dimension. This content fingerprint-based verification mechanism can accurately identify and intercept codebase state changes caused by concurrent commits, branch merging, or environment drift, preventing logical misalignment, conflict introduction, or regression risks caused by "using old patches to fix new code". This provides deterministic spatiotemporal alignment assurance for automated repair merging, significantly improving the credibility of repair results and engineering security.

[0149] In one embodiment, to ensure the traceability and tamper-proof nature of the repair process, the verification credentials are encapsulated as a standardized verification receipt. This verification receipt not only includes the aforementioned fault characteristic hash, patch content hash, and environment fingerprint, but also integrates the following key fields:

[0150] A unique receipt ID, a globally unique identifier generated based on the fault signature and patch hash, is used to associate the entire lifecycle record of this repair.

[0151] The timestamp and validity period record the precise time of successful verification and allow setting a validity window for receipts to prevent replay attacks on expired receipts.

[0152] Cryptographic signatures are used to digitally sign the core fields of a receipt using the asymmetric private key of the verification controller, ensuring that the receipt has not been tampered with during transmission and storage and that its source is trustworthy.

[0153] Audit metadata includes the node identifier that performed the verification, the test case version used, and the difference log digest hash of the counterfactual verification.

[0154] When the system receives a verification receipt and prepares to merge the code, it first performs receipt signature verification and integrity checks. Code merging permissions are only triggered if the receipt is valid. Simultaneously, the verification receipt is written to a blockchain-based notarization system or an immutable audit log, serving as the legally binding deliverable of this automated remediation operation. In the event of a future online incident retrospective, operations personnel can quickly locate the remediation context, verification environment status, and decision-making basis using the verification receipt, achieving auditable remediation.

[0155] In one example, it also includes:

[0156] Maintain a history table to record the fault signatures of structured fault data that has been processed;

[0157] Before constructing the repair context, query the history table to see if there is a fault signature identical to the current fault;

[0158] If the same fault signature exists, the repair process for the current fault is stopped.

[0159] In this example, by maintaining a fault signature history table of structured fault data and performing signature deduplication before building the repair context, the system achieves automatic identification and process interception of duplicate faults. This deduplication mechanism based on unique signatures effectively avoids redundant analysis and model inference calls for the same known fault. It not only significantly reduces the consumption of computing resources and system load, but also prevents invalid patch generation or potential conflict risks caused by repeatedly triggering the same repair process, thereby improving the overall operating efficiency and engineering economy of the code repair system.

[0160] The method provided in the embodiments of this specification captures the fault state in a multi-stage operation chain and generates structured fault data. By combining code change records and project resource dependencies, it can accurately filter out a set of candidate resources that are directly or indirectly related to the root cause of the fault from all resources, while clearly defining a subset of writable resources that are allowed to be modified. This refined filtering mechanism based on causal dependency analysis effectively eliminates a large amount of code noise that is unrelated to the fault and strictly constrains the modification permissions of the model. It can accurately define the context range and modifiable boundaries required for repair, thereby improving the repair accuracy.

[0161] Figure 4 This diagram illustrates a deduplication method based on fault signatures according to one embodiment. The method can be based on... Figure 1 The implementation scenarios shown and Figure 2 An example of a method for fixing application code is shown. Figure 4 As shown, the deduplication method based on fault signatures in this embodiment includes the following steps: Step 41, obtain the current fault signature; Step 42, query the historical record table; Step 43, determine whether a matching record exists; Step 44, if a matching record exists, stop the repair process; Step 45, if no matching record exists, execute the standard repair process; Step 46, update the historical record table. The specific execution method of each of the above steps is described below.

[0162] First, in step 41, the current fault signature is obtained. It can be understood that the fault signature is not directly derived from the original error log, but is a unique identifier extracted or calculated based on the structured fault data generated in the preceding steps (such as step 21).

[0163] The fault signature is generated by combining deterministic fault characteristic information (including stable features such as error codes, critical stack frames, and module identifiers after noise reduction) with a runtime input state digest (generated based on the hash values ​​of code files involved in the runtime phase, dependency lock files, environment configuration information, and executed commands) and applying a hash algorithm or other mapping rules. Because this signature eliminates non-deterministic noise such as timestamps and process IDs, and is tightly bound to the code and environment baseline at the time of the fault, it can uniquely and stably represent the specific fault nature in a specific context, providing accurate matching criteria for subsequent historical record queries and deduplication.

[0164] Then, in step 42, the history table is queried. It can be understood that the history table is a persistent or cached data structure (such as a database table, key-value store, or in-memory hash table) maintained by the system to store fault signatures of processed structured fault data and their corresponding processing status (e.g., a valid patch has been generated, the repair verification has passed, the repair failed, or it has been manually marked as ignored).

[0165] In this embodiment of the specification, the system uses the current fault signature obtained in step 41 as the index key to search the historical record table for a completely matching entry. This query process aims to quickly determine whether the current fault belongs to a known or recurring fault scenario, thereby providing data support for subsequent process branch decisions.

[0166] Next, in step 43, it is determined whether a matching record exists. Understandably, in step 43, the system performs a logical check on the query results from step 32.

[0167] In the embodiments described in this specification, the system checks whether a valid record that is completely consistent with the current fault signature is returned in the historical record table. If the query result shows that a matching record exists, the current fault is determined to be a duplicate fault or a known fault, meaning that the fault scenario has been captured and processed by the system before (regardless of whether the processing result was successful repair, verification failure, or being marked as ignored); if the query result shows that no matching record exists, the current fault is determined to be a newly occurring fault.

[0168] In step 44, if a matching record exists, the repair process is stopped. It can be understood that in step 44, when step 43 determines that a matching record exists, the system terminates the repair process.

[0169] In this embodiment, since the signature of the current fault is completely consistent with the entry in the history table, it indicates that the fault scenario has been previously captured and processed by the system (e.g., a candidate patch has been generated, verification is underway, or it has been marked as not needing repair). Therefore, continuing to execute subsequent resource filtering, context construction, and large model inference will not only fail to provide new repair value but will also waste computing resources and increase system load. Based on this, the system directly interrupts the current code repair task chain, no longer sends requests to the code repair model, and no longer performs subsequent patch verification and merging operations. At the same time, the system can return the corresponding status identifier (such as "duplicate fault", "processing", or "ignored") to the caller so that the upstream system can log or prompt the user, thereby achieving efficient interception and deduplication of known faults.

[0170] In step 45, if no matching record is found, the standard repair procedure is executed. It can be understood that in step 45, when step 43 determines that no matching record exists, the system initiates the standard code repair process.

[0171] In this embodiment, since no corresponding entry was found in the historical record table for the current fault signature, it indicates that the fault is a newly occurring fault or an abnormal scenario that has not been previously captured by the system. Therefore, it is necessary to execute complete causal analysis and automated repair logic. The system will execute the following core steps in sequence: First, based on structured fault data, obtain the code change records and project resource dependency information before the fault occurred; then, use the change information to identify potential risk sources, and combine the dependency graph to filter out a set of candidate resources that are directly or indirectly related to the root cause of the fault from all resources, while dividing the writable resource subset that is allowed to be modified; then, extract the relevant resource content to construct a repair context containing permission constraints, and send a request to the code repair model to generate candidate patches; finally, perform boundary verification, dual-environment verification, and baseline consistency checks on the generated patches, and merge them into the code repository after meeting all preset conditions. This process ensures a comprehensive response and accurate repair for unknown faults.

[0172] Finally, in step 46, the history record table is updated. It can be understood that in step 46, the system performs an update operation on the history record table to complete the closed loop of the deduplication mechanism.

[0173] In the embodiments described in this specification, after the standard repair process for the current fault is completed (regardless of whether the final result is successful generation and merging of a candidate patch, verification failure leading to repair termination, or being marked as ignored for other reasons), the system writes or updates the unique fault signature of the current fault and its corresponding final processing status (e.g., "Repair successful", "Verification failed", "Model has no solution", or "Manual intervention") as a new record to the historical record table. This update operation ensures that the fault scenario is persistently marked as "processed", thereby ensuring that when an anomaly with the same fault signature is detected again, steps 42 and 43 can accurately hit the record and trigger the deduplication interception logic in step 44; at the same time, by recording the processing results, the system can also provide data support for subsequent fault statistical analysis, model effect evaluation, and operation and maintenance decisions, realizing full lifecycle management from fault perception and automatic repair to knowledge accumulation.

[0174] Figure 5 This diagram illustrates the principle of constructing causal slicing based on a dependency graph according to one embodiment. Figure 5 As shown, the construction process includes the following four stages in sequence:

[0175] Phase 1: Construction of the full project resource dependency graph.

[0176] The system first performs static analysis on the target application, parsing source code import relationships, configuration file references, and build rules to construct a dependency graph covering all project resources. This graph serves as the topological foundation for subsequent analysis, containing all possible code call chains and data flow paths.

[0177] Phase Two: Backward Slicing.

[0178] The system uses the error-throwing point in the structured fault data (such as the top-level frame of the exception stack) as the slicing criterion to perform a backward slicing algorithm on the full project resource dependency graph. Specifically, starting from the error-throwing point, it traverses backward along the control flow and data flow edges, collecting all variable definitions, function calls, and conditional judgment nodes that may affect the error point, forming an initial static causal slice set. This step aims to extract all code nodes with potential causal relationships to the fault phenomenon from the full dependency graph.

[0179] Phase 3: Change intersection filtering.

[0180] The system performs an intersection operation on the aforementioned static causal slice set and the "recent change record set". Since faults are usually introduced by recent code modifications, the intersection operation can significantly eliminate stable code (i.e., "noise code") that has not changed for a long time but is on the causal path, retaining only resource nodes that are both on the fault propagation path and fall within the scope of recent changes, thereby significantly narrowing the search scope.

[0181] Phase 4: Confidence Weighting and Pruning.

[0182] For the remaining nodes after intersection filtering, the system performs a confidence-weighted calculation based on their hop count from the error-prone point, their frequency of occurrence in the historical fault database, and the matching degree of the runtime state summary. Subsequently, an intelligent pruning strategy is executed: edge nodes or long-tail dependent paths with confidence scores below a preset threshold are removed. This step further removes resources with weak indirect correlations or high false alarm rates, ensuring that the final output set has an extremely high signal-to-noise ratio.

[0183] Output a set of candidate resources.

[0184] After four stages of screening and optimization, the system finally outputs a minimal set of candidate resources. This set, as a core component of the repair context, ensures the completeness of the information containing the root causes of the faults while minimizing the interference of irrelevant code on the code repair model, thereby improving the accuracy and efficiency of automated repair.

[0185] Figure 6 A timing flowchart illustrating a dual-environment counterfactual verification according to one embodiment is shown. Figure 6 As shown, this verification process is led by the verification controller. It confirms the causal validity of the patches by comparing the control environment (keeping the original fault code) and the processing environment (applying candidate patches) in parallel. Before executing specific steps, initialization is performed based on the same baseline and environment snapshot. The verification controller ensures that the control and processing environments are completely consistent across all dimensions, including operating system, dependency libraries, configuration files, and code baselines, providing a reliable benchmark for subsequent differential comparisons. The specific steps are as follows:

[0186] Step 61: Apply candidate patches only to the processing environment. The verification controller deploys the candidate patches to be verified to the processing environment, while the control environment remains unchanged from the original code state at the time of the failure. This step constructs the "intervention variable" in counterfactual reasoning, where the only difference is the presence or absence of the patch.

[0187] Steps 62 and 63 involve injecting deterministic test input. The verification controller injects identical deterministic test input into both the control and processing environments. This input is generated based on a runtime state summary from structured fault data, ensuring that the execution start point, parameters, and random seed are completely consistent between the two environments, eliminating the interference of non-deterministic factors on the verification results.

[0188] Step 64: Compare the returned execution result A (expected fault reproduction) to the environment. Execute the original fault code in the environment; the returned execution result A should stably reproduce the abnormal behavior described in the structured fault data (such as specific error codes, stack traces, or timeouts). If it is not reproduced, it indicates that the current environment state does not match the fault, and the verification process can be terminated early.

[0189] Step 65: The processing environment returns execution result B (expected fault elimination). The processing environment executes the code that has applied the candidate patch, and its returned execution result B should indicate that the fault has been eliminated and the business process has been completed normally or returned a success status.

[0190] Step 66: If verification passes, a verification credential is generated. The verification controller compares execution result A with execution result B. Verification is considered successful only if both conditions are met simultaneously: "reproducing the fault in the control environment" and "eliminating the fault in the processing environment." At this point, the system generates a verification credential containing the fault characteristic hash, patch content hash, environment fingerprint, and difference log summary, which serves as the sole trusted basis for subsequent code merging.

[0191] Step 67: If verification fails, discard the patch. Verification fails if any of the following occurs: (1) the fault is not reproduced in the control environment; (2) the fault is not eliminated in the processing environment; or (3) a new anomaly or regression error is introduced in the processing environment. The verification controller will discard the candidate patch and may trigger a feedback mechanism to notify the code repair model to be regenerated or to be manually intervened.

[0192] pass Figure 6 The verification sequence shown demonstrates that this scheme, based on the core principle of "single variable control," scientifically proves the causal relationship between patches and fault elimination through rigorous parallel comparative experiments, thereby ensuring the safety and reliability of automated repair.

[0193] According to another embodiment, an application code repair apparatus is also provided, which is used to perform the methods provided in the embodiments of this specification. Figure 7 A schematic block diagram of an application code repair device according to one embodiment is shown. Figure 7 As shown, the device 700 includes:

[0194] The generation unit 71 is used to monitor the execution status of the target application in the multi-stage execution chain. When a failure is detected in a certain stage, it captures the error log and the running environment status, and generates structured fault data containing the fault stage identifier and standardized error characteristics.

[0195] The acquisition unit 72 is used to acquire code change records and dependency information between project resources before the fault occurred based on the structured fault data generated by the generation unit 71.

[0196] The filtering unit 73 is used to determine the set of resources that have recently changed by using the code change records obtained by the acquisition unit 72, and to filter out the set of candidate resources that have direct or indirect dependency relationships with the root cause of the failure from the full set of project resources in combination with the dependency relationship information obtained by the acquisition unit.

[0197] Repair unit 74 is used to extract resource content from the candidate resource set obtained by the filtering unit 73 to construct a repair context, send a request containing the repair context to the code repair model, and receive candidate patches returned by the code repair model, wherein the candidate patches contain code change instructions to be executed.

[0198] Optionally, as an embodiment, the normalized error features include a fault signature, deterministic fault feature information, and a runtime input state summary;

[0199] The generation unit 71 includes:

[0200] The cleaning subunit is used to clean the error log, remove nondeterministic information, and retain deterministic fault characteristic information, including error codes, key stack frames, and module identifiers.

[0201] The summary subunit is used to calculate a summary of the runtime input state before the failure occurs. The summary of the runtime input state is generated based on the hash values ​​of the code files involved in the runtime phase, the hash values ​​of the dependency lock files, the environment configuration information, and the executed commands.

[0202] The signature subunit is used to generate a unique fault signature based on the deterministic fault feature information obtained by the cleaning subunit and the runtime input state summary obtained by the summary subunit.

[0203] The encapsulation subunit is used to encapsulate the fault stage identifier, the fault signature obtained by the signature subunit, the deterministic fault feature information obtained by the cleaning subunit, and the runtime input state summary obtained by the summary subunit to form the structured fault data.

[0204] Optionally, as an embodiment, the filtering unit 73 includes:

[0205] The determination subunit is used to determine the initial root resource set, which includes the file directly pointed to by the error log, the resources associated with the structured error, and the configuration files necessary for the current fault stage.

[0206] The acquisition subunit is used to obtain the set of resources that were modified in the current run before the failure occurred, using the code change record;

[0207] The search sub-unit is used to recursively search for resources that have import, reference, contain, or generate relationships with the modified resource set obtained by the acquisition sub-unit, starting from the initial root resource set obtained by the determined sub-unit, based on the project resource dependency graph, until a preset depth threshold or confidence threshold is reached, thus forming the candidate resource set.

[0208] Furthermore, the project resource dependency graph describes at least one of the following dependencies:

[0209] Code import or reference relationships between source code files;

[0210] The calling or version constraints between source code files and third-party dependency packages;

[0211] The configuration file contains references to resource files, routing rules, or build targets;

[0212] The build tool generates output files based on the input files, representing a build relationship.

[0213] Optionally, as an embodiment, the filtering unit 73 further includes:

[0214] The judgment subunit is used to traverse each resource in the candidate resource set and determine whether it meets the writable condition. The writable condition includes whether the resource has a creation, modification or deletion record in the code change record of this run; or whether the resource belongs to the necessary repair root specified by the current fault phase strategy and can provide corresponding phase input evidence. The necessary repair root includes dependency manifest file, lock file or routing configuration file.

[0215] The first marking subunit is used to mark a resource as a writable resource and add it to the writable resource subset if the judgment result of the judgment subunit is that the resource meets the writable condition.

[0216] The second marking subunit is used to mark a resource as a read-only resource if the judgment result of the judgment subunit is that the resource does not meet the writable condition.

[0217] Optionally, as an embodiment, the candidate resource set is further divided into a writable subset that can be modified, and includes:

[0218] A verification unit is used to verify whether all the resources to be modified by the candidate patch belong to the writable resource subset.

[0219] The merging unit is used to merge the candidate patch into the codebase of the target application under preset conditions if the verification unit passes the verification.

[0220] Furthermore, the verification unit includes:

[0221] The parsing subunit is used to parse the candidate patch and extract the write set declared therein, the write set containing resource identifiers to be added, modified or deleted;

[0222] A comparison subunit is used to compare the write set obtained from the parsing subunit with the writable resource subset.

[0223] The first verification subunit is configured to pass the verification if the comparison subunit finds that the write set is a subset of the writable resource subset.

[0224] The second verification subunit is used to fail the verification and reject the candidate patch if the comparison subunit finds that there are resources in the write set that do not belong to the writable resource subset.

[0225] Furthermore, the merging unit includes:

[0226] A subunit is created to create two isolated execution environments based on the code baseline and environment snapshot before the failure occurred: a control environment without the patch applied and a processing environment with the candidate patch applied.

[0227] The credential generation subunit is used to perform the same verification process in the control environment and the processing environment created by the creation subunit. If the control environment reproduces the fault corresponding to the structured fault data, and the processing environment eliminates the fault and meets the preset acceptance conditions, then a verification credential containing fault characteristics, patch content and verification results is generated.

[0228] The merge subunit is used to merge the candidate patch into the target application's codebase based on the verification credential when the current active codebase's state is consistent with the baseline state bound to the verification credential generated by the credential generation subunit.

[0229] Furthermore, the acceptance criteria include:

[0230] The baseline version of the current active workspace is consistent with the baseline version used when the structured fault data was generated;

[0231] The hash values ​​of each resource in the candidate resource set in the current active workspace are consistent with the state summary before the failure occurred.

[0232] Optionally, as an embodiment, it also includes:

[0233] The recording unit is used to maintain a historical record table, which records the fault signatures of the structured fault data that has been processed;

[0234] The query unit is used to query the historical record table obtained by the recording unit to see if there is a fault signature that is the same as the current fault before constructing the repair context;

[0235] The stop unit is used to stop the repair process for the current fault if the query unit finds that the same fault signature exists.

[0236] The apparatus provided in the embodiments of this specification captures the fault status in a multi-stage operation chain and generates structured fault data through the generation unit 71. The filtering unit 73, combined with the code change records and project resource dependencies obtained by the acquisition unit 72, can accurately filter out a set of candidate resources that are directly or indirectly related to the root cause of the fault from all resources, and clearly delineate the writable resource subset that is allowed to be modified. This refined filtering mechanism based on causal dependency analysis effectively eliminates a large amount of code noise that is unrelated to the fault and strictly constrains the modification permissions of the model. It can accurately define the context range and modifiable boundaries required for repair, thereby improving the repair accuracy of the repair unit 74.

[0237] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figures 2 to 6 Any of the methods described.

[0238] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figures 2 to 6 Any of the methods described.

[0239] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0240] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for fixing application code, comprising: Monitor the execution status of the target application in a multi-stage execution chain. When a failure is detected in a certain stage, capture the error log and runtime environment status, and generate structured fault data containing fault stage identifiers and standardized error characteristics. Based on the structured fault data, obtain the code change records and dependency information between project resources before the fault occurred; The code change record is used to determine the set of resources that have recently changed, and combined with the dependency information, a set of candidate resources that have direct or indirect dependency relationships with the root cause of the failure is selected from all project resources. Extract resource content from the candidate resource set to construct a repair context, send a request containing the repair context to the code repair model, and receive candidate patches returned by the code repair model, wherein the candidate patches contain code change instructions to be executed.

2. The method as described in claim 1, wherein, The standardized error features include fault signatures, deterministic fault feature information, and runtime input state summaries; The generation of structured fault data, which includes fault stage identifiers and standardized error features, includes: The error log is cleaned to remove nondeterministic information and retain deterministic fault characteristic information, including error codes, key stack frames, and module identifiers. Calculate a runtime input state summary before the failure occurs, which is generated based on the hash values ​​of code files involved in the runtime phase, the hash values ​​of dependency lock files, environment configuration information, and executed commands. Based on the deterministic fault feature information and the runtime input state summary, a unique fault signature is generated; The fault stage identifier, the fault signature, the deterministic fault feature information, and the runtime input state summary are encapsulated to form the structured fault data.

3. The method as described in claim 1, wherein, The set of candidate resources selected from all project resources that have a direct or indirect dependency relationship with the root cause of the failure includes: Determine the initial root resource set, which includes the file directly pointed to by the error log, resources associated with structured errors, and configuration files necessary for the current fault stage; Using the code change record, obtain the set of resources that were modified in the current run before the failure occurred; Based on the project resource dependency graph, starting from the initial root resource set, resources that have import, reference, contain, or generate relationships with the modified resource set are recursively searched until a preset depth threshold or confidence threshold is reached, thus forming the candidate resource set.

4. The method of claim 3, wherein, The project resource dependency graph describes at least one of the following dependencies: Code import or reference relationships between source code files; The calling or version constraints between source code files and third-party dependency packages; The configuration file contains references to resource files, routing rules, or build targets; The build tool generates output files based on the input files, representing a build relationship.

5. The method of claim 1, wherein, Also includes: Iterate through each resource in the candidate resource set and determine whether it satisfies the writable condition; The writable conditions include: the resource has been created, modified, or deleted in the code change record of this run; or, the resource belongs to the necessary repair root specified by the current fault phase strategy and can provide corresponding phase input evidence; wherein, the necessary repair root includes dependency manifest file, lock file, or route configuration file; If the determination result is that the resource meets the writable condition, then mark it as a writable resource and add it to the writable resource subset; If the determination result is that the resource does not meet the writable condition, then it is marked as a read-only resource.

6. The method of claim 1, wherein, The candidate resource set is divided into a writable subset that is allowed to be modified, and also includes: Verify whether all resources to be modified by the candidate patches belong to the writable resource subset; If the verification passes, the candidate patch will be merged into the target application's codebase under preset conditions.

7. The method of claim 6, wherein, The verification of whether all resources to be modified by the candidate patch belong to the writable resource subset includes: The candidate patch is parsed, and the write set declared therein is extracted. The write set contains the resource identifiers to be added, modified or deleted. Compare the write set with the writable resource subset; If the write set is a subset of the writable resource subset, then the verification passes; If there are resources in the write set that do not belong to the writable resource subset, the verification fails and the candidate patch is rejected.

8. The method of claim 6, wherein, The step of merging the candidate patch into the target application's codebase under preset conditions includes: Based on the code baseline and environment snapshot before the failure, two isolated execution environments are created: a control environment without the patch applied and a processing environment with the candidate patch applied. The same verification process is performed in the control environment and the processing environment. If the control environment reproduces the fault corresponding to the structured fault data, and the processing environment eliminates the fault and meets the preset acceptance conditions, a verification certificate containing fault characteristics, patch content and verification results is generated. When the current active codebase state matches the baseline state bound to the verification credential, the candidate patch is merged into the target application's codebase based on the verification credential.

9. The method of claim 8, wherein, The acceptance criteria include: The baseline version of the current active workspace is consistent with the baseline version used when the structured fault data was generated; The hash values ​​of each resource in the candidate resource set in the current active workspace are consistent with the state summary before the failure occurred.

10. The method of claim 1, wherein, Also includes: Maintain a history table to record the fault signatures of structured fault data that has been processed; Before constructing the repair context, query the history table to see if there is a fault signature identical to the current fault; If the same fault signature exists, the repair process for the current fault is stopped.

11. An application code repair device, comprising: The generation unit is used to monitor the execution status of the target application in a multi-stage execution chain. When a failure is detected in a certain stage, it captures error logs and runtime environment status, and generates structured fault data containing fault stage identifiers and standardized error characteristics. The acquisition unit is used to acquire code change records and dependency information between project resources before the fault occurred, based on the structured fault data generated by the generation unit. The filtering unit is used to determine the set of resources that have recently changed by using the code change records obtained by the acquisition unit, and to filter out the set of candidate resources that have a direct or indirect dependency relationship with the root cause of the failure from the full set of project resources in combination with the dependency relationship information obtained by the acquisition unit. The repair unit is used to extract resource content from the candidate resource set obtained by the filtering unit to construct a repair context, send a request containing the repair context to the code repair model, and receive candidate patches returned by the code repair model, wherein the candidate patches contain code change instructions to be executed.

12. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-10.

Images