A front-end exception self-healing method and system based on causal playback verification

Abstract

The application discloses a front-end exception self-healing method and system based on causal playback verification, and specifically comprises the following steps: constructing an exception causal correlation graph based on a candidate change set, an exception trigger operation sequence, and an environment difference between an exception target environment and a control environment; determining a root cause candidate along the exception causal correlation graph, and generating a candidate repair patch for the root cause candidate; deploying the candidate repair patch to an isolated playback sandbox corresponding to the exception target environment and the control environment, replaying the exception trigger operation sequence to obtain a patch verification result; and outputting a target repair patch with a patch verification confidence reaching a preset threshold, a corresponding exception causal correlation graph, and a rollback application instruction to an interactive terminal. The application improves the limitations of existing manual investigation of multi-factor associated exceptions and the defects of automatic repair lacking regression verification, and can perform causal playback verification under real environment differences and user operation paths.

Description

Technical Field

[0001] This invention relates to the field of software anomaly detection technology, and in particular to a front-end anomaly self-healing method and system based on causal replay verification. Background Technology

[0002] As the complexity of front-end applications continues to increase, issues such as JavaScript exceptions, resource loading errors, and API response anomalies are becoming increasingly common. Existing front-end exception monitoring systems can collect these exception logs and categorize and aggregate them according to error type, access address, or exception stack trace. However, most systems only provide a visual representation of exception information. After receiving alerts, developers still need to repeatedly switch between monitoring platforms, code repositories, command-line tools, dependency management interfaces, and integrated development environments, manually comparing data to try to determine the causal relationship between the exception and recent code commits, dependency changes, user runtime environment, and specific operational processes. This process relies on personal experience, has a long investigation cycle, and is prone to overlooking key related factors due to scattered information, making it difficult to achieve rapid and accurate root cause localization of exceptions.

[0003] In terms of automated patching, existing technologies typically generate patches by matching pre-defined patch templates based on exception types or by making local code changes only based on the location where the exception was thrown. These methods rely on a single dimension of information and cannot identify coupled front-end exceptions caused by the combined effects of browser kernel differences, third-party dependency version upgrades, batch changes in canary releases, specific user operation paths, and overlapping environment configuration items. More importantly, even if a patch is generated, existing solutions generally lack closed-loop verification of the patch's effectiveness and security. Whether the exception has truly been eliminated after the patch, whether new functional regressions have been introduced in the normal environment, and whether the patch logic matches the differences between the target environment and the control environment cannot be confirmed. This results in insufficient reliability of the automated patching results, making it difficult to directly apply them to production environments. Summary of the Invention

[0004] The purpose of this invention is to provide a front-end anomaly self-healing method and system based on causal replay verification, which improves the limitations of existing manual investigation of multi-factor correlation anomalies and the lack of regression verification in automatic repair. It can perform causal replay verification under real-world environmental differences and user operation paths, thereby improving the accuracy, reliability and delivery security of front-end anomaly repair, and effectively reducing the duration of production accidents caused by the coupling of code changes, dependency upgrades and environmental differences, so as to solve at least one of the above-mentioned problems in the prior art.

[0005] In a first aspect, the present invention provides a front-end anomaly self-healing method based on causal replay verification, the method specifically comprising: In response to diagnostic commands sent by the interactive terminal, the monitoring interface with two-way authentication obtains the abnormal logs, session traces and runtime environment fingerprints within the target time window and encapsulates them into abnormal diagnostic data. Based on the anomaly diagnostic data, the commit differences, dependency lock files, and source mapping files in the corresponding time range in the code repository are associated to obtain a candidate change set; An abnormal triggering operation sequence is generated based on the session trajectory. The abnormal target environment and control environment are determined based on the abnormal log and runtime environment fingerprint. An abnormal causal relationship graph is constructed based on the candidate change set, the abnormal triggering operation sequence, and the environmental differences between the abnormal target environment and the control environment. Candidate root causes are identified along the abnormal causal relationship graph, and candidate repair patches are generated for the candidate root causes. Deploy candidate patch to the isolation replay sandbox corresponding to the abnormal target environment and the control environment, and replay the abnormal triggering operation sequence to obtain patch verification results; Based on the patch verification results and the correlation strength of root cause candidates, the patch verification confidence level is determined. The target repair patch with a patch verification confidence level reaching a preset threshold, the corresponding abnormal causal relationship graph, and the rollback application instruction are output to the interactive terminal.

[0006] Secondly, this invention provides a front-end anomaly self-healing system based on causal replay verification, the system specifically comprising: The data encapsulation module is used to respond to diagnostic commands sent by the interactive terminal, obtain abnormal logs, session traces and runtime environment fingerprints within the target time window through a two-way authenticated monitoring interface, and encapsulate them into abnormal diagnostic data. The change determination module is used to obtain a candidate change set by associating commit differences, dependency lock files and source mapping files in the code repository within the corresponding time range based on anomaly diagnostic data. The causal association module is used to generate anomaly trigger operation sequences based on session trajectories, determine the anomaly target environment and control environment based on anomaly logs and runtime environment fingerprints, and construct anomaly causal association graph based on candidate change sets, anomaly trigger operation sequences, and environmental differences between the anomaly target environment and control environment. The patch generation module is used to identify root cause candidates along the abnormal causal relationship graph and generate candidate repair patches for the root cause candidates. The patch verification module is used to deploy candidate patch remediation to the isolation replay sandboxes corresponding to the abnormal target environment and the control environment, and replay the abnormal triggering operation sequence to obtain patch verification results; The patch return module is used to determine the patch verification confidence level based on the patch verification results and the correlation strength of root cause candidates, and output the target repair patch with the patch verification confidence level reaching the preset threshold, the corresponding abnormal causal relationship graph, and the rollback application instruction to the interactive terminal.

[0007] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements the front-end anomaly self-healing method based on causal replay verification as described in any of the above methods.

[0008] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the front-end anomaly self-healing method based on causal replay verification as described in any of the above methods.

[0009] Compared with the prior art, the present invention has at least one of the following technical effects: 1. It improves upon the limitations of existing manual investigation of multi-factor correlation anomalies and the lack of regression verification in automatic repair. It can perform causal replay verification under real-world environmental differences and user operation paths, improving the accuracy, reliability, and delivery security of front-end anomaly repair, and effectively reducing the duration of production accidents caused by code changes, dependency upgrades, and environmental differences.

[0010] 2. Through a two-way authenticated monitoring interface, abnormal logs, session traces, and runtime environment fingerprints within the target time window are automatically extracted based on diagnostic commands and encapsulated with a unified diagnostic association identifier. This avoids the authentication risks and fragmentation issues associated with manual cross-system data collection, ensuring that the full picture of the abnormal situation is completely and securely restored.

[0011] 3. Automatically associates anomaly diagnostic data with commit differences, dependency lock files, and source mapping files in the code repository. It can accurately map the compressed runtime code coordinates to the source file code lines and simultaneously lock dependency version changes, generating a high-coverage candidate change set and eliminating the uncertainty of manually finding change sources.

[0012] 4. Automatically extract and clean event records from the conversation trajectory, and combine them with exception markers and time sequence backtracking to generate an executable exception triggering operation sequence containing operation instructions and interface waiting conditions, so that the real interaction process of the user triggering the exception can be accurately and without redundancy replayed in the sandbox.

[0013] 5. The system automatically identifies the target environment for anomalies using runtime environment fingerprints and selects the control environment that has not experienced anomalies and has the fewest environmental differences, quantifying the dimensions of environmental differences. This provides a clear benchmark for the subsequent construction of causal relationship diagrams, making the contribution of environmental factors (such as browser version and dependencies) to anomalies explicit.

[0014] 6. Associate candidate change nodes, exception triggering operation nodes, and environmental difference nodes, and quantify the association strength based on temporal proximity, call frequency, and environmental difference matching. This enables the effective decomposition of complex exceptions caused by multi-factor coupling (such as the combined effects of code changes, specific operations, and environmental differences), and thereby identifies root cause candidates.

[0015] 7. Deploy the candidate patch to the isolation replay sandboxes of both the target and control environments simultaneously, and replay the same operation sequence. By comparing the abnormal states before and after patch deployment, as well as the execution results of the target and control environments, verification results of anomaly elimination and functional regression can be obtained in one go, ensuring that the repair does not damage normal functionality.

[0016] 8. By integrating the objective scoring of patch verification with the root cause correlation strength of the causal relationship graph, the confidence level of patch verification is quantified. Only target-fix patches that meet the standards are output, along with a complete anomaly causal relationship graph and rollback instructions. This provides operations and maintenance personnel with a clear basis for the reliability of self-healing solutions and enables secure deployment and rollback capabilities. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating a front-end anomaly self-healing method based on causal replay verification provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the timing process for acquiring abnormal diagnostic data according to an embodiment of the present invention; Figure 3 This is a schematic diagram of constructing an abnormal causal relationship graph according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a front-end anomaly self-healing system based on causal replay verification provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0020] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0021] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating a front-end anomaly self-healing method based on causal replay verification, as disclosed in an embodiment of the present invention, is shown below in detail: S101, in response to the diagnostic command sent by the interactive terminal, obtains the abnormal logs, session traces and runtime environment fingerprints within the target time window through the two-way authenticated monitoring interface, and encapsulates them into abnormal diagnostic data; S102, Based on the anomaly diagnosis data, the commit differences, dependency lock files and source mapping files in the code repository corresponding to the time range are associated with the code repository to obtain a candidate change set; S103, Generate an abnormal triggering operation sequence based on the session trajectory, determine the abnormal target environment and control environment based on the abnormal log and runtime environment fingerprint, and construct an abnormal causal relationship graph based on the candidate change set, the abnormal triggering operation sequence and the environmental differences between the abnormal target environment and the control environment. S104, determine root cause candidates along the abnormal causal relationship graph, and generate candidate repair patches for root cause candidates; S105, deploy the candidate patch to the isolation replay sandbox corresponding to the abnormal target environment and the control environment, and replay the abnormal triggering operation sequence to obtain the patch verification result; S106. Based on the patch verification results and the correlation strength of root cause candidates, determine the patch verification confidence level, and output the target repair patch with the patch verification confidence level reaching the preset threshold, the corresponding abnormal causal relationship diagram, and the rollback application instruction to the interactive terminal.

[0022] In this embodiment, the interactive terminal can be a management terminal or an operation and maintenance terminal used by developers, the monitoring interface is used to provide exception logs, session traces and runtime environment information, the code repository system is used to provide commit differences, dependency lock files and source mapping files, and the isolation replay sandbox is used to verify candidate fix patches without affecting the production environment.

[0023] When a developer initiates a diagnostic command for a front-end anomaly in the interactive terminal, the system first responds to the command and obtains anomaly data within the target time window through a two-way authenticated monitoring interface. This two-way authentication can be implemented based on client certificates, interface tokens, or other trusted authentication mechanisms to ensure the security of the anomaly data acquisition process. Based on the project identifier, anomaly filtering conditions, and target time window in the diagnostic command, the system obtains corresponding JavaScript anomaly logs, resource loading error logs, and interface response anomaly logs. Furthermore, based on the user identifier, session identifier, or tracing identifier in the anomaly logs, the system correlates and obtains session traces such as page access, clicks, inputs, route jumps, and interface calls within the same session. Simultaneously, the system extracts information such as browser type and version, operating system information, page address, network status, application build version, dependency versions, and configuration items from the anomaly logs and session traces to form a runtime environment fingerprint. Subsequently, the system configures the same diagnostic association identifier for the anomaly logs, session traces, and runtime environment fingerprint, and encapsulates them into anomaly diagnostic data.

[0024] After obtaining the anomaly diagnostic data, the system correlates the resource addresses, anomaly timestamps, compressed code coordinates, and application build identifiers with commit differences within the corresponding time range in the code repository. Specifically, the system can determine the target build commit corresponding to the anomaly based on the application build identifier, and determine the code change range that may affect that build version based on the anomaly timestamp, thereby obtaining the commit differences within that range. For the compressed code after the front-end build, the system further reads the corresponding source mapping file, mapping the compressed code location in the anomaly log to the source file and code line to determine the relationship between the anomaly location and source code changes. Simultaneously, the system reads the dependency lock file corresponding to the target build commit to identify changes to third-party dependencies, build tool versions, or runtime dependency versions. Through the comprehensive correlation of the above commit differences, dependency version changes, and source file mapping results, the system obtains a candidate change set.

[0025] Subsequently, the system generates an exception-triggered operation sequence based on the session trajectory. Specifically, the system extracts trajectory event records from the session trajectory, which may include event occurrence time, event type, operation object location information, operation parameters, interface response status, and exception markers. The system uses the occurrence time of the exception event record as the backtracking endpoint, filters trajectory event records within a preset backtracking period in the same session, and arranges them in chronological order. For continuously repeating trajectory events or those with no substantial impact on exception triggering, they can be merged or deleted to obtain an operation sequence more suitable for playback execution. The system generates executable operation instructions based on the event type, operation object location information, and operation parameters, and generates corresponding waiting conditions based on the interface response status, thereby forming the exception-triggered operation sequence.

[0026] Based on the generated anomaly triggering operation sequence, the system further determines the target environment and control environment based on anomaly logs and runtime environment fingerprints. The target environment can be the runtime environment represented by the combination of the browser, operating system, application version, dependency versions, and configuration items that actually caused the anomaly. The control environment can be a runtime environment that did not generate the same anomaly within a similar timeframe and has a high degree of similarity to the target environment. The system selects environments with fewer differences and no associated anomaly logs as control environments by comparing environmental differences such as terminal type, operating system version, browser kernel version, application version, dependency versions, and configuration items. Therefore, in subsequent verification, it can simultaneously determine whether the patch can eliminate the problem in the target environment and whether it will disrupt normal functionality in the control environment.

[0027] Next, the system constructs an anomaly causal relationship graph based on the candidate change set, the anomaly triggering operation sequence, and the environmental differences between the anomaly target environment and the control environment. The anomaly causal relationship graph can include change nodes, operation nodes, and environment nodes. Change nodes represent code changes, dependency changes, or source file locations within the candidate change set; operation nodes represent operation instructions, waiting conditions, and interface response statuses in the anomaly triggering operation sequence; and environment nodes represent browser version differences, dependency version differences, configuration item differences, or canary release batch differences between the anomaly target environment and the control environment. The system establishes association edges between nodes based on code call relationships, interface association relationships, occurrence sequence, version dependency relationships, and configuration reference relationships. It determines the association strength based on factors such as temporal proximity, call count, and environmental difference matching, thereby forming an anomaly causal relationship graph that characterizes the propagation relationship of the anomaly's cause.

[0028] After constructing the anomaly causal relationship graph, the system determines root cause candidates along the graph. Specifically, the system can identify the node corresponding to the anomaly log as the anomaly starting node and traverse backwards along the edges pointing to that starting node to find change nodes and environment nodes that have a causal relationship with it. For each relationship path, the system comprehensively considers the relationship strength, path length, and node type to determine the root cause relationship strength between the corresponding node and the anomaly. When the root cause relationship strength of a change node or environment node reaches a preset screening threshold, the system identifies it as a root cause candidate. For example, when a dependency version upgrade node and a specific browser kernel version node both point to an interface response anomaly or a page rendering anomaly, the system can identify the dependency version upgrade and its related code call location as root cause candidates. Subsequently, the system generates candidate repair patches based on the code change content, dependency version information, or configuration difference information corresponding to the root cause candidates. These candidate repair patches may include code rollback patches, compatibility handling patches, dependency version locking patches, configuration adjustment patches, or conditional branch repair patches, etc.

[0029] To prevent unverified patches from being directly applied to the production environment, the system deploys candidate patch remediation sandboxes to the corresponding isolated replay sandboxes of the abnormal target environment and the control environment for verification. Specifically, based on the runtime environment fingerprints of the abnormal target environment and the control environment, the system creates separate replay sandboxes for the target environment and the control environment, loading the corresponding application version, dependency versions, configuration items, and terminal execution parameters into each sandbox. Subsequently, the system loads the candidate patch into each of the two replay sandboxes and replays it according to the operation sequence triggered by the anomaly. During the replay, the system collects page status, interface response results, anomaly logs, operation sequence execution completion status, and functionality retention status. By comparing the results in the target environment replay sandbox with the anomaly logs before patch deployment, the system can determine whether the candidate patch has eliminated the original anomaly; by comparing the results in the control environment replay sandbox with the original normal state, the system can determine whether the candidate patch has introduced new functional regressions. Thus, the system obtains the patch verification results.

[0030] Finally, the system determines the patch verification confidence level based on the patch verification results and the correlation strength of root cause candidates. Specifically, the system can extract the anomaly elimination status, operation sequence execution completion status, interface response consistency, and control environment function maintenance status from the patch verification results, and combine this with the correlation strength of the root cause candidates that generated the candidate patch in the anomaly causal relationship graph to determine the patch verification confidence level. When the patch verification confidence level of a candidate patch reaches a preset threshold, the system identifies it as the target patch. Subsequently, the system generates a rollback application instruction based on the target patch. The rollback application instruction may include patch identifier, applicable version, deployment scope, activation conditions, rollback version, and rollback trigger conditions. Finally, the system outputs the target patch, the corresponding anomaly causal relationship graph, and the rollback application instruction to the interactive terminal for developers to review, confirm, or further release.

[0031] Through the above implementation methods, this application not only unifies the association of exception logs, session traces, runtime environment fingerprints, code commit differences, dependency changes, and source mapping relationships, but also identifies candidate root causes of exceptions based on the exception causal relationship graph. Furthermore, it verifies the effectiveness and security of candidate repair patches through isolated replay verification in the exception target environment and the control environment. Compared to methods that only display exception information or generate patches solely based on exception locations, this application reduces manual investigation costs, improves the accuracy of front-end exception root cause localization, and enhances the reliability of automatic repair results before production application.

[0032] In some embodiments, in step S101 above, the step of responding to the diagnostic command sent by the interactive terminal, obtaining the abnormal logs, session traces, and runtime environment fingerprints within the target time window through the two-way authenticated monitoring interface, and encapsulating them into abnormal diagnostic data, specifically includes: Parse diagnostic commands to obtain project identifiers, anomaly filtering criteria, and target time windows; Two-way authentication is completed based on client certificates and monitoring interfaces, and access authorization corresponding to the project identifier is obtained; Based on access authorization, send an abnormal data query request to the monitoring interface, and obtain abnormal logs according to the abnormal filtering conditions and target time window; Obtain the session trajectory by associating it with the user identifier, session identifier, or link tracing identifier in the anomaly log; Extract browser information, operating system information, page address, network status, application build version and dependency versions from exception logs and session traces to generate runtime environment fingerprints; Configure the same diagnostic association identifier for exception logs, session traces, and runtime environment fingerprints, and encapsulate them as exception diagnostic data.

[0033] In this embodiment, when the interactive terminal detects a front-end anomaly to be diagnosed, developers or operations personnel can send a diagnostic command through the interactive terminal. The diagnostic command typically includes at least a project identifier, anomaly filtering conditions, and a target time window. Upon receiving the diagnostic command, the diagnostic service module first parses it to determine the specific project scope, anomaly type range, and time range requiring diagnosis, avoiding the retrieval of irrelevant data and thus improving diagnostic efficiency.

[0034] After completing instruction parsing, the diagnostic service module performs two-way authentication between the client certificate and the monitoring interface. This two-way authentication verifies the legitimacy of the interactive terminal or diagnostic service module, and also confirms the trustworthiness of the data access channel connected to the monitoring interface, thereby preventing unauthorized access or tampering of abnormal data during the acquisition process. Upon successful authentication, the monitoring interface returns an access authorization corresponding to the project identifier to the diagnostic service module. This access authorization limits the scope and permission boundaries of subsequent query requests.

[0035] After obtaining access authorization, the diagnostic service module sends an anomaly data query request to the monitoring interface and retrieves anomaly logs from the monitoring data source according to the anomaly filtering criteria and target time window. The anomaly logs may include front-end anomaly records such as JavaScript anomalies, resource loading failures, interface timeouts, status code anomalies, and route redirection anomalies. To ensure traceability between the logs and actual user operations, the system further correlates and retrieves the corresponding session trajectory based on the user identifier, session identifier, or tracing identifier in the anomaly logs. The session trajectory can be used to reconstruct the user interaction process before and after the anomaly occurred, such as page opening, button clicking, input, scrolling, tab switching, and interface calls, thus providing a foundation for constructing the subsequent anomaly triggering operation sequence.

[0036] Meanwhile, the diagnostic service module extracts fields such as browser information, operating system information, page address, network status, application build version, and dependent versions from the exception logs and session logs to generate a runtime environment fingerprint. This runtime environment fingerprint is used to characterize the runtime context at the time of the exception, enabling subsequent identification of whether the exception is related to a specific browser kernel, system environment, version release batch, or dependency upgrade. To ensure data consistency, the system also configures the same diagnostic association identifier for the exception logs, session logs, and runtime environment fingerprints, and encapsulates all three into exception diagnostic data. In this way, when subsequent modules perform change comparison, cause-effect graph construction, or patch verification, they can quickly locate all context information of the same exception event using the same diagnostic association identifier as an index.

[0037] Combination Figure 2 As shown, Figure 2From left to right, the system comprises four objects: the interactive terminal, the diagnostic service module, the monitoring interface, and the monitoring data source. The interactive terminal first sends a diagnostic command to the diagnostic service module. After parsing the command, the module sends a diagnostic request to the monitoring interface. Upon receiving access authorization from the monitoring interface, the diagnostic service module uses this authorization to send an anomaly data query request. The monitoring interface then queries the monitoring data source for data within the target time window, retrieves anomaly logs and session traces, and returns them to the diagnostic service module. Based on this, the diagnostic service module generates a runtime environment fingerprint and encapsulates the anomaly diagnostic data, ultimately returning the data to the interactive terminal or for use in subsequent steps. Figure 2 The message flow shown illustrates a complete closed loop from "instruction input" to "authorization verification" and then to "abnormal data recycling and encapsulation," which can intuitively explain the data acquisition logic, access control logic, and diagnostic data organization method of this step.

[0038] Through the above implementation methods, this application establishes a unified association between anomaly logs, session trajectories, and runtime environment fingerprints during the anomaly diagnosis stage. This not only improves the integrity of diagnostic data but also provides a reliable data foundation for subsequent candidate change set association, anomaly causal analysis, and replay verification.

[0039] In some embodiments, step S102 above, which involves obtaining a candidate change set based on commit differences, dependency lock files, and source mapping files within the corresponding time range in the associated code repository based on anomaly diagnostic data, specifically includes: Extract resource addresses, compressed code coordinates, anomaly timestamps, and application build identifiers from anomaly diagnostic data; The target build commit in the code repository is determined based on the application build identifier, and the code change range is determined based on the exception timestamp. Retrieve commit differences within the code change range and associate them with source file changes corresponding to the resource addresses; Read the dependency lock file corresponding to the target build commit to determine dependency version changes; Based on the application build identifier and resource address, obtain the source mapping file from the build artifact repository or monitoring platform, and use the source mapping file to map the compressed code coordinates to the source files and lines of code; A candidate change set is generated based on the mapping results of commit differences, dependency version changes, and source files and lines of code.

[0040] In this embodiment, after obtaining the anomaly diagnostic data, the system further associates the anomaly diagnostic data with the code repository, dependency lock files, and source mapping files to obtain a candidate change set. This candidate change set is used to limit the code and dependency scope of subsequent causal analysis, avoiding aimless investigation of the entire code repository based solely on anomaly stacks or human experience.

[0041] Specifically, the diagnostic service module first extracts resource addresses, compressed code coordinates, exception timestamps, and application build identifiers from the anomaly diagnostic data. The resource address can be the address of a script file, style file, or resource package loaded by the browser when the exception occurred; the compressed code coordinates can include line numbers, column numbers, or offset positions within the compressed script file; the exception timestamp indicates the actual time the exception occurred; and the application build identifier indicates the front-end build version corresponding to the exception, such as the build batch number, release version number, or commit identifier. By extracting this information, the system can pinpoint runtime exceptions to specific build artifacts and their corresponding code versions.

[0042] Subsequently, the system identifies the target build commit in the code repository based on the application build identifier. For front-end applications released through a continuous integration system, the application build identifier typically corresponds to a commit, a tag, or a build record in the code repository. The system can use this correspondence to determine the target build commit that occurred when the exception occurred. Simultaneously, the system determines the code change interval based on the exception timestamp. This code change interval can be the commit range between the target build commit and the previous stable build commit, or it can be the commit range within a preset time period before the exception first occurred. In this way, the system can narrow down the candidate investigation scope to the set of changes related to the exception occurrence time and the release version.

[0043] After determining the code change range, the system retrieves the commit differences within that range and further associates them with the source file changes corresponding to the resource addresses. Specifically, if the resource address in the exception log points to a built script package, the system can determine the range of source files contained in that script package based on the build manifest, packaging configuration, or module mapping relationships, and then filter the added, deleted, or modified content related to that source file range from the commit differences. In this way, even if the exception log only records the built resource address, the system can still associate it with the actual source code changes.

[0044] Simultaneously, the system reads the dependency lock file corresponding to the target build commit to determine dependency version changes. Dependency lock files can be files used in front-end projects to fix third-party dependency versions, such as lock files generated by package managers. By comparing the dependency lock files in the target build commit with those in the reference commit, the system identifies version changes of third-party libraries, build tools, runtime components, or indirect dependencies. For front-end anomalies, dependency upgrades, changes in indirect dependencies, or changes in build tool versions can all affect runtime behavior; therefore, including dependency version changes in the candidate change set helps to discover anomaly causes that are difficult to pinpoint based solely on source code differences.

[0045] In addition, the system retrieves the corresponding source mapping file from the build artifact repository or monitoring platform based on the application build identifier and resource address. The source mapping file describes the location mapping relationship between the compressed, merged, or transpiled build artifacts and the original source files. The system uses this source mapping file to map the coordinates of compressed code in the anomaly diagnostic data to the source files and lines of code. For example, when the anomaly log only records a row and column position in the compressed script, the system can determine the corresponding original source code file, function, or statement range through the source mapping file. This mapping process improves the accuracy of anomaly location and avoids distortion in anomaly location caused by front-end code compression, obfuscation, merging, and other build processes.

[0046] Finally, the system generates a candidate change set based on the commit differences, dependency version changes, and the mapping results of source files and lines of code. The candidate change set may include source file modifications related to the abnormal resource address, code modifications adjacent to or related to the abnormal line of code, dependency version changes in the target build commit, and configuration changes related to build artifacts or runtime behavior. Each candidate change item may carry information such as change type, change source, commit, associated file, corresponding code location, and dependency version information for subsequent use in constructing the anomaly causal relationship graph.

[0047] Through the above implementation methods, this application does not only investigate based on the surface location in the exception stack, but also correlates runtime exception data with code repository commits, dependency lock files, and source mapping files in a multi-dimensional way, thereby obtaining a more complete and accurate candidate change set. This candidate change set can cover not only source code changes, but also dependency version changes and build artifact mapping results, providing a reliable basis for subsequent root cause localization and patch generation.

[0048] In some embodiments, step S103 above, which involves generating an exception triggering operation sequence based on the session trajectory, specifically includes: Extract trajectory event records from the session trajectory. The trajectory event records include session identifier, occurrence time, event type, operation object location information, operation parameters, interface response status, and exception marker. Anomaly event records are identified based on anomaly markers, and the occurrence time of the anomaly event record is used as the backtracking endpoint to filter trajectory event records that have the same session identifier as the anomaly event record and are located within a preset backtracking period. Sort the selected trajectory event records according to the occurrence time, and delete adjacent duplicate trajectory event records; Based on the event type, operation object location information and operation parameters in the sorted trajectory event records, generate executable operation instructions, and generate waiting conditions corresponding to the executable operation instructions based on the interface response status; The executable operation instructions and waiting conditions are concatenated in the order of occurrence time of the trajectory event records corresponding to the executable operation instructions to generate an abnormal trigger operation sequence.

[0049] In this embodiment, the system generates an anomaly triggering operation sequence based on the session trajectory in the anomaly diagnostic data, so as to reproduce the anomaly occurrence process in the subsequent isolation playback sandbox. The anomaly triggering operation sequence is not simply a record of user operation names, but rather organizes the page interaction actions and the corresponding page loading and interface response waiting states according to the actual operation order in the original session, thereby improving the accuracy of anomaly reproduction.

[0050] Specifically, the system first extracts trajectory event records from the session trajectory. Each trajectory event record includes at least a session identifier, occurrence time, event type, operation object location information, operation parameters, interface response status, and anomaly flag. The session identifier distinguishes operation records from different users or different access processes; the occurrence time determines the sequence of events; the event type can include page access, route redirection, click, input, selection, submission, scrolling, interface request, interface response, and resource loading; the operation object location information uniquely or nearly uniquely locates the operated object on the page, such as page address, element identifier, element attribute, component path, or accessibility identifier; the operation parameters can include input text, option values, page redirection parameters, or submission parameters; the interface response status indicates whether the relevant interface request was completed and its response result; and the anomaly flag indicates whether the trajectory event directly corresponds to a target anomaly.

[0051] Then, the system identifies exception event records based on exception markers. These exception event records can be trajectory events associated with JavaScript exceptions, resource loading failures, API response exceptions, or page rendering exceptions. The system uses the occurrence time of the exception event record as the backtracking endpoint, filtering the session trajectory for records with the same session identifier as the exception event record and located within a preset backtracking time period. The preset backtracking time period can be configured based on the exception type, page complexity, or session duration; for example, it can backtrack the operations performed several minutes before the exception occurred. By limiting the backtracking time period to the same session identifier, irrelevant operational errors from other users or other sessions can be avoided from being included in the exception reproduction process.

[0052] For the filtered trajectory event records, the system sorts them according to their occurrence time to restore the user's actual operation sequence. Considering that factors such as front-end tracking, repeated clicks, network retransmissions, or repeated rendering of page components may generate consecutive events with the same or substantially equivalent content, the system deletes or merges adjacent duplicate trajectory event records. Specifically, when adjacent events have the same event type, the same operation object location information, and the same operation parameters, and the time interval between their occurrences is less than a preset interval, subsequent duplicate events can be deleted. For input events with the same operation object but different operation parameters, the last valid input event can be retained so that the operation sequence reflects the final actual input content. This processing can reduce meaningless replays and lower the possibility that replay results deviate from the actual session due to repeated submissions or clicks.

[0053] After obtaining the sorted and deduplicated trajectory event records, the system generates executable operation instructions based on the event type, the location information of the operation object, and the operation parameters. For example, for page access or route navigation events, operation instructions can be generated to access the corresponding page address or navigate to a specified route; for click events, operation instructions can be generated to click on the page element determined by the location information of the operation object; for input events, operation instructions can be generated to fill in the content represented by the operation parameters into the corresponding input object; for selection or submission events, corresponding operation instructions can be generated for option selection, form submission, or confirmation.

[0054] Simultaneously, the system generates waiting conditions based on the interface response status associated with each operation instruction. These waiting conditions control the execution sequence between operation instructions to simulate the order of page state changes and asynchronous request completion in the original session. For example, when a click operation triggers an interface request, the system can generate waiting conditions based on the interface response status, such as waiting for the corresponding interface to return, waiting for the page to load completely, waiting for a specified element to appear, or waiting for a specified state to be updated. When the interface response is abnormal or times out, the corresponding failure or timeout status can also be retained to ensure that the replay process can reproduce the actual operating conditions when the exception occurred as accurately as possible. By setting waiting conditions, the system avoids executing the next operation prematurely before the previous page state has been updated, thereby improving the consistency of exception replay.

[0055] Finally, the system sequentially concatenates the executable operation instructions and their corresponding waiting conditions according to the occurrence time sequence of the trajectory events corresponding to the executable operation instructions, forming an anomaly triggering operation sequence. This sequence may include page initialization operations, user interaction operations, page redirection operations, interface response waiting operations, and key status confirmation operations before the anomaly is triggered. The system then deploys this anomaly triggering operation sequence to an isolated playback sandbox matching the target anomaly environment to verify whether the target anomaly can be reproduced and to evaluate the repair effectiveness of candidate patches.

[0056] Through the above implementation method, the system can automatically extract key operations that are temporally and sessionally related to the occurrence of the anomaly from the original session trajectory and convert them into an anomaly triggering operation sequence that can be executed in the playback environment. Compared with the method of reproducing based solely on the anomaly stack or manual description, this method can more accurately preserve the user operation path, interface waiting relationship, and anomaly triggering context, providing a reliable foundation for root cause localization and repair verification of front-end anomalies.

[0057] In some embodiments, step S103 above, determining the abnormal target environment and the reference environment based on the abnormal log and the runtime environment fingerprint, specifically includes: Extract the source environment instance identifier from the anomaly log, locate the corresponding target fingerprint record in the runtime environment fingerprint based on the source environment instance identifier, and determine the runtime environment represented by the target fingerprint record as the anomaly target environment; Based on the collection time of the target fingerprint record, other environmental fingerprint records that are not associated with abnormal logs within a preset time range are filtered out; By comparing the terminal type, operating system version, browser kernel version, application version, dependency version, and configuration items in other environmental fingerprint records with the target fingerprint record, the environmental differences are obtained; The operating environment characterized by the environmental fingerprint record with the fewest environmental differences is identified as the control environment.

[0058] In this embodiment, the system determines the target environment and control environment for anomalies based on anomaly logs and runtime environment fingerprints, providing a comparable runtime basis for anomaly reproduction, root cause localization, and patch verification. The target environment refers to the environment actually hosting the application when the target anomaly occurs; the control environment refers to the runtime environment that does not experience the target anomaly, provided it has a high degree of similarity to the target environment. By comparing the two, the scope of investigation can be effectively narrowed down to identify anomalies that may be caused by environmental differences, version differences, or configuration differences.

[0059] Specifically, the system first extracts the source environment instance identifier from the exception log. This source environment instance identifier can be a browser session instance identifier, terminal device instance identifier, container instance identifier, virtual machine instance identifier, application deployment instance identifier, or other unique identifier that can distinguish a specific runtime environment. This identifier is typically written by the client monitoring component, application monitoring component, or runtime environment collection component when the exception log is generated, and is used to establish the association between the exception record and the runtime environment record.

[0060] Based on the source environment instance identifier, the system locates the corresponding target fingerprint record in the runtime environment fingerprint. The runtime environment fingerprint record may include terminal type, operating system version, browser kernel version, browser version, application version, application build identifier, dependency versions, network status, and runtime configuration items. The terminal type may include desktop terminals, mobile terminals, tablet terminals, or other terminal categories; configuration items may include parameters that affect application runtime behavior, such as function switch status, gray-scale release flags, interface access addresses, region configurations, browser security policies, or cache configurations. The system identifies the runtime environment represented by the target fingerprint record as the abnormal target environment, ensuring that abnormal logs, session traces, build versions, and environment parameters are uniformly attributed to the actual environment at the time of the abnormality.

[0061] After identifying the abnormal target environment, the system uses the collection time of the target fingerprint record as a time benchmark to filter other environment fingerprint records without associated abnormal logs within a preset time range. The preset time range can be a predetermined period before and / or after the target fingerprint record's collection time, such as the same release batch, the same gray-scale period, or the same peak business period. By using environment fingerprint records with similar times as the filtering targets, interference caused by application version iterations, changes in server interface status, changes in business data, or adjustments to release strategies can be minimized. The "unassociated abnormal logs" refer to abnormal logs that do not record the target abnormal type within the corresponding environment instance, session, or preset association period, or environment records whose abnormal state meets preset normal judgment conditions.

[0062] Subsequently, the system compares the selected environmental fingerprint records with the target fingerprint record item by item to obtain environmental differences. The comparison fields include at least terminal type, operating system version, browser kernel version, application version, dependent versions, and configuration items. For discrete attributes such as terminal type, operating system version, browser kernel version, and application version, differences can be determined by whether the field values ​​are consistent. For dependent versions, differences between directly and indirectly dependent versions can be identified. For configuration items, differences can be identified regarding function on / off status, grayscale indicators, interface domain names, regional parameters, and security policy parameters. If necessary, the system can also include contextual information related to the anomaly, such as network status, page address, login status, or user role, in the comparison to improve the effectiveness of the comparison environment.

[0063] The system counts the number of environmental differences between each other environmental fingerprint record and the target fingerprint record, and identifies the operating environment represented by the environmental fingerprint record with the fewest environmental differences as the control environment. If multiple environmental fingerprint records have the same and fewest differences, they can be further filtered according to the time distance from the target environment, consistency of application build identifiers, consistency of network status, or similarity of session operation paths, prioritizing environments with closer time distance, the same application version, and fewer configuration differences as control environments. The control environments obtained in this way are consistent with the abnormal target environment under most operating conditions, while not exhibiting the target anomaly, thus having high diagnostic reference value.

[0064] Using the above method, the system can automatically select the normal environment that is most similar to the abnormal target environment from a large number of runtime environment records, rather than comparing the abnormal environment with any normal environment. Subsequently, based on the environmental differences between the abnormal target environment and the control environment, it can be determined whether the target anomaly may be related to browser compatibility, operating system differences, dependency version changes, gray-scale configuration, or feature on / off status, and accordingly, an anomaly reproduction environment and patch verification environment that are closer to the actual running scenario can be constructed.

[0065] In some embodiments, step S103 above, which involves constructing an anomaly causal relationship graph based on the candidate change set, the anomaly triggering operation sequence, and the environmental differences between the anomaly target environment and the control environment, specifically includes: Associate the anomaly locations in the anomaly log with the candidate change set to generate change nodes; An operation node is generated based on the operation instructions, waiting conditions, and interface response status in the abnormal trigger operation sequence. Environment nodes are generated based on the environmental differences between the abnormal target environment and the control environment. Establish the first association edge based on the code call relationship, interface association relationship, and occurrence sequence between the change node and the operation node. Establish a second association edge based on the version dependency and configuration reference relationship between the change node and the environment node; The association strength is determined based on the temporal proximity, call count, and environmental difference matching of the first and second associated edges, resulting in an abnormal causal association graph.

[0066] In this embodiment, the system constructs an anomaly causal relationship graph based on candidate change sets, anomaly triggering operation sequences, and environmental differences between the target environment and the control environment. This graph structurally correlates the location of the anomaly, user operation processes, code and dependency changes, and differences in the operating environment, identifying potential causes highly correlated with the target anomaly from multiple dimensions. This provides a basis for subsequent root cause ranking, remediation strategy generation, and remediation verification.

[0067] Specifically, the system first associates the anomaly location in the anomaly log with a candidate change set to generate change nodes. The anomaly location can include the source file path, code line / column position, compressed resource address, compressed code coordinates, function name, or module identifier in the anomaly stack. The system can combine the source mapping file to convert the compressed code coordinates into the corresponding source file and source code location, and then match them with commit differences, source file changes, and dependency version changes in the candidate change set. For code modifications that are the same as, near, or on the anomaly call chain, or associated with the anomaly resource package, code change nodes are generated. For third-party libraries, indirect dependencies, or runtime components that have changed in the target build version and may affect the operation of the anomaly module, dependency change nodes are generated. For source files located at the anomaly location through source mapping, source file nodes are generated. Each change node can carry attributes such as commit identifier, change time, change type, file path, code location, dependency version, and a summary of the change content.

[0068] The system further generates operation nodes based on the abnormal triggering operation sequence. Specifically, for executable operation instructions such as page access, page navigation, click, input, selection, and submission in the operation sequence, corresponding operation instruction nodes are generated; for records such as interface requests, interface responses, interface timeouts, or interface error returns triggered during operation execution, interface nodes are generated; and for abnormal events, abnormal page states, or abnormal response results corresponding to abnormal triggering, abnormal nodes are generated. Operation nodes can record information such as operation occurrence time, operation object location information, operation parameters, associated page address, interface identifier, response status, and abnormal flags. Waiting conditions, as state constraints for operation execution, can be used to characterize the page loading completion relationship, interface response completion relationship, target element appearance relationship, or timeout relationship between preceding and subsequent operations, thus enabling the operation associations in the graph to reflect the temporal dependencies in the actual session.

[0069] The system also generates environment nodes based on the environmental differences between the abnormal target environment and the control environment. These environment nodes may include version difference nodes, configuration difference nodes, and terminal difference nodes. Version difference nodes represent differences in application version, build version, browser kernel version, operating system version, or dependent versions; configuration difference nodes represent differences in feature switches, grayscale markings, interface addresses, security policies, caching policies, or regional configurations; and terminal difference nodes represent differences in terminal type, device capabilities, or browser operating characteristics. Environment nodes can record the actual values ​​in the target environment, the corresponding values ​​in the control environment, and the categories of differences between the two, thereby clearly defining the characteristics of the abnormal environment compared to the normal control environment.

[0070] After a node is generated, the system establishes the first association edge between the change node and the operation node. This first association edge can be determined based on code call relationships, interface association relationships, and the timing of occurrence. Specifically, when the function, module, or source file corresponding to the code change node can respond to an operation instruction, or is triggered by that operation instruction, a code call association can be established between them; when the code change node involves interface request construction, response parsing, status handling, or error handling logic, and is consistent with the interface associated with the operation node, an interface association can be established between them; when the function corresponding to the code change is called before the abnormal operation, and the call time and the abnormal occurrence time are within a preset proximity range, a timing association can be established. Abnormal nodes can also establish associations with the operation instruction node, interface node, and related code change nodes that triggered them, forming a path from operation triggering to abnormal occurrence.

[0071] The system also establishes a second association edge between change nodes and environment nodes. For dependency change nodes, a version dependency association edge can be established when there is an adaptation, compatibility, or conflict relationship between its dependency version and the application version, browser version, runtime version, or terminal environment represented by the environment node. For example, if a dependency upgrade only triggers a compatibility issue under a specific browser kernel version, an association can be established between the dependency change node and the browser version difference node. For code change nodes or source file nodes, a configuration reference association edge can be established with the corresponding configuration difference node when it reads, judges, passes, or affects a configuration item. For example, if different processing branches are controlled by a function switch in the code, and the abnormal target environment and the control environment differ in the value of the function switch, an association can be established between the relevant code change node and the function switch configuration difference node.

[0072] After establishing the first and second associated edges, the system determines the association strength based on the temporal proximity, call count, and environmental difference matching of each associated edge. Temporal proximity characterizes the proximity of operations, interface calls, code execution, and exception occurrences in time; the smaller the time interval, the stronger the association. Call count characterizes the frequency with which the corresponding operation, interface, or code path is actually executed in the exception session; paths that occur repeatedly and co-occur with the exception have a higher association. Environmental difference matching characterizes whether code changes or dependency changes match the version, configuration, or terminal differences specific to the exception target environment. When a change is triggered only under the corresponding configuration or version conditions in the exception target environment, but not in the control environment, the strength of the associated edge between the changed node and the corresponding environment node can be increased. Finally, the system generates an exception causal relationship graph based on the nodes and associated edges with association strengths.

[0073] Combination Figure 3As shown, the anomaly causal relationship graph can be divided into an operation node region, a change node region, and an environment node region. The operation node region includes operation instruction nodes, interface nodes, and anomaly nodes, used to describe the execution process from user operation to interface interaction to the occurrence of the anomaly. The change node region includes code change nodes, dependency change nodes, and source file nodes, used to describe changes in code, dependencies, and files that may affect the anomaly during the target build submission. The environment node region includes version difference nodes, configuration difference nodes, and terminal difference nodes, used to describe the environmental differences between the target environment and the control environment.

[0074] like Figure 3 As shown, the change node area and the operation node area are connected by a first association edge. For example, a code change node can be associated with an operation instruction node through code call relationships, a dependency change node can be associated with an interface node through interface processing or runtime call relationships, and a source file node can be associated with an exception node through exception location mapping or exception call chain relationships. The change node area and the environment node area are connected by a second association edge. For example, a code change node or dependency change node can establish a version dependency relationship with a version difference node, a dependency change node or source file node can establish a configuration reference relationship with a configuration difference node, and a source file node can also establish a browser compatibility or terminal adaptation relationship with a terminal difference node. Figure 3 The connection relationships shown are used to illustrate typical association methods between various types of nodes, and do not limit the nodes to establishing connections only according to the one-to-one correspondence shown in the diagram. In practical applications, a change node can be associated with multiple operation nodes and multiple environment nodes, and an environment difference node can also be associated with multiple code, dependency, or source file nodes.

[0075] The anomaly causal relationship graph constructed in the above manner can unify "what operation triggered the anomaly," "what code or dependency changes were involved in the anomaly," and "what environmental differences occurred when the anomaly occurred" into a single relationship structure. The subsequent system can then identify highly correlated change nodes and high-risk environmental difference nodes based on the strength of the relationship, determine the priority causes of the anomaly to be investigated, and generate targeted remediation candidate solutions.

[0076] In some embodiments, step S104 above, which involves determining root cause candidates along the abnormal causal relationship graph and generating candidate repair patches for the root cause candidates, specifically includes: The node in the abnormal cause-effect graph that corresponds to the abnormal log is identified as the abnormal starting node. Traverse backwards along the associated edges pointing to the originating node of the anomaly to obtain the change nodes and environment nodes that have a causal relationship with the originating node of the anomaly. The root cause correlation strength is determined based on the correlation paths, correlation strength, and path length of each change node and each environment node to the anomaly initiation node. Nodes whose root cause association strength reaches a preset screening threshold are identified as root cause candidates. Based on the code changes, dependency version information, or configuration differences corresponding to the root cause candidates, generate candidate fix patches.

[0077] In this embodiment, the system identifies root cause candidates in the constructed anomaly causal relationship graph and generates candidate repair patches for these root cause candidates. The anomaly causal relationship graph includes anomaly nodes, operation nodes, interface nodes, code change nodes, dependency change nodes, source file nodes, and environment nodes. Nodes are connected by edges representing code call relationships, interface relationships, temporal relationships, version dependencies, or configuration reference relationships. Each edge has a corresponding association strength, indicating the degree to which two nodes are likely associated with the target anomaly.

[0078] Specifically, the system first identifies the nodes in the exception causal relationship graph corresponding to the exception logs as the exception initiation nodes. These initiation nodes can be located by the exception type, exception stack trace, exception location, occurrence time, source environment instance identifier, interface error information, or exception markers in the exception logs. For example, when the exception log records a page script execution error, the initiation node can be the exception node corresponding to the location of that script error; when the exception log records an interface timeout, interface response failure, or data parsing failure, the initiation node can be the corresponding interface exception node or page state exception node. If the same exception log is associated with multiple exception nodes, the system can use all exception nodes as the initiation node, or select one or more nodes for subsequent analysis based on the match degree of the exception location and the proximity of the time.

[0079] After identifying the anomaly initiation node, the system performs a reverse traversal along the associated edges pointing to the initiation node to obtain change nodes and environment nodes with causal transitive relationships to the initiation node. This reverse traversal refers to tracing back from the anomaly result to possible triggering operations, code changes, dependency changes, version differences, configuration differences, and terminal differences, following the direction of influence indicated by the associated edges. For example, the system can trace back from the anomaly node to the corresponding interface node or operation instruction node, and then to the code change nodes, dependency change nodes, and source file nodes involved in processing that interface or response; it can also trace further from the code change node or dependency change node to version difference nodes, configuration difference nodes, and terminal difference nodes that have version dependencies or configuration references with it. During the traversal, the maximum traversal depth, maximum associated path length, or minimum edge strength can be limited to exclude distant nodes with weak associations to the target anomaly and reduce invalid candidates caused by an excessively large causal graph.

[0080] For each changed node and each environment node obtained through reverse traversal, the system determines the root cause correlation strength based on the associated path from the node to the anomaly initiation node, the correlation strength of each associated edge on the path, and the path length. Specifically, when there are multiple associated paths between a candidate node and the anomaly initiation node, the degree of correlation reflected by each path can be comprehensively considered. When the associated edges in the path all have high correlation strength, and the path is short and has few intermediate nodes, it indicates that there is a relatively direct causal transmission relationship between the candidate node and the anomaly initiation node, and its root cause correlation strength is correspondingly high. Conversely, if a node needs to go through many intermediate nodes to be associated with the anomaly initiation node, or if the path contains associated edges with low correlation strength, the root cause correlation strength of the node is reduced.

[0081] Furthermore, for environment nodes, the system can also determine their root cause association strength by combining the difference matching results between the abnormal target environment and the control environment. For example, when a certain function switch, browser kernel version, dependency version, or terminal type exists only in the abnormal target environment, and the associated code path is actually executed under the conditions of that environment, while the corresponding conditions do not appear and no target exception occurs in the control environment, the root cause association strength of the corresponding environment node and related change nodes can be increased. For change nodes, the system can also use the change submission time, the time of the first occurrence of the exception, and the scope of the change's impact for auxiliary judgment. If the time of the first occurrence of the exception is adjacent to the time of a certain code submission, dependency upgrade, or configuration release, and the location of the exception or the call chain matches the content of the change, the root cause association strength of that change node can be increased.

[0082] The system identifies nodes whose root cause correlation strength reaches a preset screening threshold as root cause candidates. These root cause candidates may include code change candidates, dependency change candidates, configuration difference candidates, version difference candidates, or terminal compatibility candidates. The preset screening threshold can be configured based on historical anomaly handling results, graph size, or an upper limit on the number of candidates. In actual processing, the system can also sort candidate nodes according to root cause correlation strength and select a predetermined number of top-ranked nodes as root cause candidates to ensure the efficiency of subsequent patch generation and verification processes.

[0083] After identifying root cause candidates, the system generates candidate repair patches based on the node type and associated information of the root cause candidates. For code change candidates, the system generates code repair patches to correct exception handling logic, parameter validation logic, null value handling logic, asynchronous state control logic, browser compatibility logic, or boundary condition judgment logic, based on the corresponding code change content, exception location, source file context, and call chain relationship. For dependency change candidates, the system generates repair patches to roll back dependency versions, upgrade dependency versions, lock compatible versions, replace dependency components, or adjust dependency loading order, based on dependency version information, dependency call location, and version compatibility relationships. For configuration difference candidates, the system generates repair patches to adjust function switch states, correct grayscale ranges, modify interface addresses, supplement default configuration values, or add configuration validity checks, based on the configuration difference information between the exception target environment and the control environment.

[0084] For root cause candidates related to version or terminal differences, candidate fix patches may include adaptation solutions, such as adding compatibility branches for specific browser kernels or operating system versions, replacing incompatible application interfaces, adding capability detection and downgrade processing, or limiting the combination of risky application versions and terminal versions. The candidate fix patches may include information such as the patch's target, modification location, modification content, applicable conditions, and expected repair goals, and may be associated with corresponding root cause candidates and anomaly initiation nodes to facilitate automated replay verification in the anomaly target environment and control environment.

[0085] Through the above implementation methods, the system can trace back from abnormal results to code, dependencies, and environmental factors that have a direct or indirect causal relationship with the abnormality, and filter high-confidence root cause candidates based on the association path and association strength. Based on this, candidate repair patches matching the root cause type are generated, which can reduce the scope of manual investigation, improve the automation level of abnormality repair, and enhance the targeting of patch generation.

[0086] In some embodiments, step S105 above, which involves deploying the candidate patch to the isolation replay sandboxes corresponding to the abnormal target environment and the control environment, and replaying the abnormal triggering operation sequence to obtain the patch verification result, specifically includes: Based on the runtime environment fingerprints corresponding to the abnormal target environment and the control environment, create mutually isolated target environment replay sandboxes and control environment replay sandboxes respectively. The candidate patch is loaded into the application version in the target environment replay sandbox and the control environment replay sandbox respectively, and the dependency version, configuration items and terminal execution parameters that match the fingerprint of each runtime environment are injected. In the target environment replay sandbox and the control environment replay sandbox, the abnormal trigger operation sequence is replayed according to the operation time sequence, and the page status, interface response results and abnormal logs are collected respectively. The patch verification results are obtained by comparing the replay results in the target environment replay sandbox with the anomaly logs before patch deployment and the replay results in the control environment replay sandbox.

[0087] In this embodiment, the system deploys candidate patch remediation to isolated replay sandboxes corresponding to the abnormal target environment and the control environment, and replays the abnormal triggering operation sequence to obtain the verification results of the candidate patch remediation. By performing patch verification simultaneously in the abnormal target environment and the control environment, it can be determined whether the patch eliminates the target abnormality, or whether the patch introduces new abnormalities, functional degradation, or interface compatibility issues into the originally normal operating environment.

[0088] Specifically, the system creates a target environment replay sandbox and a control environment replay sandbox based on the runtime environment fingerprints corresponding to the abnormal target environment and the control environment, respectively. The runtime environment fingerprint includes at least the terminal type, operating system version, browser kernel version, application version, dependency versions, and configuration items; where available, it may also include browser version, display parameters, language region, time zone, network policy, login status type, grayscale indicator, and security policy parameters. The target environment replay sandbox simulates the runtime conditions when the target anomaly actually occurs, while the control environment replay sandbox simulates similar runtime conditions when the target anomaly does not occur.

[0089] The isolated replay sandbox can be implemented using containers, virtual machines, browser isolation instances, terminal emulators, or a combination thereof. The target environment replay sandbox and the control environment replay sandbox are mutually isolated, including at least process isolation, file system isolation, configuration isolation, cache isolation, and log storage isolation. If necessary, they can also use independent network namespaces, independent test accounts, independent session identifiers, or interface simulation data to prevent cached states, configuration modifications, login states, or request results in one sandbox from affecting the replay results of the other. For operations requiring access to external services, interface proxies, recorded response replays, or test service instances can be used to ensure that both types of sandboxes execute the same operational procedures under controllable data conditions.

[0090] After creating the replay sandbox, the system loads candidate patch requests into the application versions in both the target environment replay sandbox and the control environment replay sandbox. Candidate patches can be code logic modifications, dependency version adjustments, configuration item adjustments, compatibility handling rules, feature switch adjustments, or API call parameter corrections. For code patches, the patch can be applied to the application build version corresponding to the exception log, generating a patch application version for replay. For dependency patches, candidate dependency versions can be injected into the corresponding dependency management scope, ensuring that non-target dependencies remain consistent with the original runtime environment. For configuration patches, target configuration items can be replaced or supplemented without changing other unrelated configuration items.

[0091] The system also injects dependency versions, configuration items, and terminal execution parameters that match the fingerprints of their respective runtime environments into the two replay sandboxes. Specifically, the target environment replay sandbox maintains the operating system version, browser kernel version, application version, dependency versions, feature on / off states, and terminal parameters corresponding to the abnormal target environment; the control environment replay sandbox maintains the runtime parameters corresponding to the control environment. For objects affected by candidate patch repairs, the patch-adjusted code, dependencies, or configuration content are used; for objects not affected by candidate patch repairs, the original values ​​recorded by their respective runtime environment fingerprints are maintained. This avoids distortion of patch verification conclusions due to the verification environment deviating from the original environment.

[0092] Subsequently, the system replays the events in the target environment replay sandbox and the control environment replay sandbox according to the operation sequence of the exception triggering operation sequence. The exception triggering operation sequence can include operation instructions such as page opening, page navigation, clicking, input, selection, submission, returning, refreshing, and waiting. For operations with waiting conditions, the system controls the execution of subsequent operations based on the corresponding page loading completion status, target element appearance status, interface response status, page state changes, or preset timeout conditions to ensure that the execution logic of the replay process is consistent with the original exception session. For interface requests involved in the operation, the system can retain the original request parameters, request order, and response dependencies; when the interface response has randomness or depends on real-time business data, it can use anonymized historical response data, preset test data, or simulated interface responses to improve the repeatability of the replay results.

[0093] During replay, the system collects page status, interface response results, and exception logs from two replay sandboxes. Page status can include whether the page has finished loading, whether the target control is displayed correctly, and whether the page is blank, laggy, has failed to redirect, has error messages, or is inoperable. Interface response results can include whether the interface request was sent successfully, the response status code, the response time, the returned data structure, the error code, and the timeout status. Exception logs can include script exceptions, resource loading exceptions, interface call exceptions, console errors, stack traces, and the time of exception occurrence. The collected results are associated and saved with the corresponding replay operation, page address, environment instance identifier, and candidate patch identifier to support subsequent traceability and repeated verification.

[0094] Finally, the system compares the replay results in the target environment replay sandbox with the anomaly logs before patch deployment, and also compares them with the replay results in the control environment replay sandbox to obtain the patch verification results. The comparison with the anomaly logs before patch deployment is used to determine whether the target anomaly has been eliminated or mitigated. For example, if the anomaly type, location, error code, or stack trace in the original anomaly logs no longer appears during the target environment replay after patch loading, and the corresponding operations can be completed, then the candidate patch can be determined to have a repair effect on the target anomaly.

[0095] The comparison with the replay results in the control environment is used to determine whether the candidate patch introduces new problems. If the sandbox replay in the control environment can still complete the operation sequence normally after loading the patch, the page status is normal, the interface response meets expectations, and no new exception logs are generated, it indicates that the patch has little impact on the original normal environment. If the patch eliminates the target exception in the target environment, but causes new page exceptions, interface failures, performance degradation, or configuration conflicts in the control environment, the patch can be marked as having regression risk, and its pass rate can be reduced.

[0096] The patch verification results can include the target anomaly elimination status, anomaly log differences, page status differences, interface response differences, regression status in the control environment, patch applicable environment, and verification conclusions. Verification conclusions can include types such as verification passed, partially passed, verification failed, and regression risk present. Specifically, verification passed indicates that the target anomaly in the target environment has been eliminated, and no new anomalies have appeared in the control environment; partially passed indicates that the anomaly has been mitigated but not completely eliminated, or that anomalies still exist in specific operation branches; verification failed indicates that the target anomaly still occurs; regression risk present indicates that although the target anomaly has been eliminated, new anomalies or functional anomalies have appeared in the control environment or other preset verification scenarios. Through this method, candidate patch repairs can be verified under isolated, reproducible, and comparable conditions, improving the reliability of patches before deployment.

[0097] In some embodiments, step S106 above, which involves determining the patch verification confidence level based on the patch verification results and the correlation strength of root cause candidates, and outputting the target repair patch with a patch verification confidence level reaching a preset threshold, the corresponding abnormal causal relationship graph, and the rollback application instruction to the interactive terminal, specifically includes: Extract the anomaly elimination status, operation sequence execution completion status, interface response consistency, and comparison environment function retention status from the patch verification results; The patch verification score is determined based on the anomaly elimination status, the completion status of the operation sequence, the consistency of the interface response, and the functional retention status of the comparison environment. Obtain the association strength of the root cause candidates corresponding to the candidate repair patches, and determine the patch validation confidence by combining the patch validation score; Candidate patch repairs whose patch verification confidence level reaches a preset threshold are identified as target patch repairs. Based on the target patch, generate a rollback application instruction that includes the patch identifier, applicable version, deployment scope, and rollback version, and output the target patch, the corresponding anomaly cause-effect graph, and the rollback application instruction to the interactive terminal.

[0098] In this embodiment, the system determines the patch verification confidence level based on the patch verification results of candidate repair patches and the correlation strength of corresponding root cause candidates. It then outputs the target repair patch with a patch verification confidence level reaching a preset threshold, the corresponding anomaly causal relationship graph, and the rollback application instruction to the interactive terminal. This implementation allows patch recommendations to be based not only on whether replay verification is successful but also on the credibility of root cause localization, thereby reducing the risk of erroneous repairs due to root cause judgment bias or insufficient verification scenarios.

[0099] Specifically, the system first extracts the anomaly elimination status, operation sequence execution completion status, interface response consistency, and control environment functionality retention status from the patch verification results. The anomaly elimination status characterizes whether the anomaly type, location, stack trace, error code, or phenomenon recorded in the anomaly log before patch deployment still appears in the target environment replay sandbox after loading the candidate patch. If the target anomaly no longer appears, or the anomaly frequency, impact range, and error level are significantly reduced, the anomaly elimination status can be determined as eliminated or improved.

[0100] The operation sequence completion status indicates whether the abnormally triggered operation sequence can be successfully executed in the target environment replay sandbox according to the predetermined sequence. The system can check whether operations such as page access, page navigation, click, input, submission, waiting, and return all achieve the expected execution results, and identify whether situations such as page freezing, missing elements, operation timeout, page navigation failure, or function interruption occur. For cases where the original abnormality occurs in the middle step of the operation sequence, in addition to determining whether the abnormal step has recovered normally, it can also determine whether subsequent operations can continue to complete, so as to avoid patches only covering up the abnormality without restoring the complete business process.

[0101] Interface response consistency is used to characterize whether the interface interaction results after patch deployment are consistent with the expected results. The system can compare the interface request order, request parameters, response status, response data structure, business error codes, and response duration in the target environment replay sandbox and the control environment replay sandbox. For interfaces unrelated to the patch, the response results should be consistent with the results recorded before patch deployment or the replay results in the control environment. For interfaces that are allowed to undergo expected changes due to patch repair, such as fixing request parameters, correcting response parsing, or adjusting interface addresses, the system can determine whether the response change belongs to an allowed change based on preset interface expectation rules. This avoids misjudging patches with abnormal interface return content, incompatible data structures, or missing key business fields as valid patches.

[0102] The control environment functionality retention status characterizes whether the previously normal operation flow and functions remain normal after a candidate patch is loaded into the control environment replay sandbox. The system can determine whether the patch introduces new script exceptions, interface failures, page display anomalies, functional unavailability, significant performance degradation, or configuration conflicts based on the control environment's page status, operation execution results, interface response results, and exception logs. If the control environment can complete the operation sequence normally without any new exceptions or unexpected interface differences, the control environment's functionality retention status is determined to be normal; otherwise, the candidate patch is marked as having regression risk.

[0103] After obtaining the above verification information, the system determines the patch verification score based on the anomaly elimination status, operation sequence execution completion status, interface response consistency, and the maintenance status of the control environment's functionality. Specifically, candidate repair patches that have completely eliminated anomalies, executed the operation sequence completely, responded as expected, and maintained normal functionality in the control environment receive a high patch verification score. If the anomaly is only partially improved, the operation sequence is only partially completed, there are differences in non-critical interface responses, or there are slight but acceptable differences in the control environment, a medium verification score can be obtained. If the target anomaly still exists, critical operations cannot be completed, critical interface responses are abnormal, or new anomalies appear in the control environment, the corresponding patch verification score is reduced, and if necessary, it can be directly determined as a failed verification.

[0104] The system further obtains the correlation strength of root cause candidates corresponding to candidate patch fixes and determines the patch verification confidence level by combining the patch verification score. The correlation strength of root cause candidates reflects the degree of causal relationship between the code changes, dependency versions, configuration differences, or terminal differences targeted by the candidate patch and the anomaly initiation node. If a root cause candidate corresponding to a patch has a short causal relationship path with the anomaly initiation node, a high correlation edge strength, and a high degree of matching with the difference characteristics of the anomaly target environment, then the correlation strength of the root cause candidate is high. Based on the patch verification score, the system refers to this correlation strength to determine the patch verification confidence level, so that patches that can both eliminate the anomaly and target highly credible root causes receive higher confidence levels; for patches that perform normally in the current replay scenario but have a weak correlation with their corresponding root causes, the confidence level can be appropriately reduced, and it can be indicated that they may be accidental evasion or non-root cause fixes.

[0105] The system identifies candidate patch verification confidence levels that reach a preset threshold as target patch repairs. This preset threshold can be configured based on business level, anomaly impact scope, system risk level, or historical patch verification accuracy. For anomalies involving high-risk businesses such as payment, authentication, and data security, a higher patch verification confidence threshold can be set; for low-risk anomalies with a smaller impact scope and quick rollback, a relatively lower threshold can be set. If multiple candidate patch repairs reach the preset threshold, the system can sort them according to patch verification confidence, regression risk, modification scope, deployment impact scope, and rollback difficulty, selecting the patch with the highest confidence level as the preferred recommended patch, or outputting multiple patches together for technical personnel to choose from.

[0106] After identifying the target patch, the system generates a rollback instruction based on the target patch. The rollback instruction includes at least a patch identifier, applicable version, deployment scope, and rollback version. The patch identifier uniquely identifies the target patch and may include a patch number, build identifier, commit identifier, or artifact identifier. The applicable version limits the range of application versions, dependent versions, or build versions that are allowed to deploy the patch. The deployment scope specifies the target audience for the patch, such as a test environment, pre-release environment, gray-scale user range, specified terminal type, specified browser version, or specified region instance. The rollback version specifies the original stable application version, dependent version, or configuration version that should be restored in case of patch verification failure, runtime anomalies, or regression risks.

[0107] In practical applications, rollback instructions can also include the canary release ratio, deployment order, rollback trigger conditions, rollback priority, and verification monitoring items. Rollback trigger conditions can include the recurrence of the target anomaly after patch deployment, an anomaly rate exceeding a preset range, increased failure rate of critical interfaces, decreased success rate of page operations, or failure to pass verification in the control environment. By clearly defining the rollback version and trigger conditions, interactive terminals or associated release management systems can quickly execute rollbacks when patch deployment anomalies occur, reducing the impact of patch deployment on business operations.

[0108] Finally, the system outputs the target fix patch, the corresponding anomaly causal relationship graph, and the rollback command to the interactive terminal. The interactive terminal can be an operations and maintenance management terminal, a development personnel terminal, an anomaly handling platform, or a release management platform. The output anomaly causal relationship graph highlights the anomaly initiation node, the root cause candidate node corresponding to the target fix patch, the main correlation path from the root cause to the anomaly, and the corresponding correlation strength, enabling technical personnel to intuitively understand the basis for the patch's fix. The target fix patch displays the patch type, modification targets, applicable environment, patch verification results, patch verification confidence level, and regression risk information; the rollback command displays the deployment scope, recommended release strategy, rollback version, and rollback trigger conditions. Thus, technical personnel can complete the review, deployment, or rollback of the target fix patch based on interpretable anomaly relationships and verification conclusions.

[0109] Reference Figure 4 An embodiment of the present invention provides a front-end anomaly self-healing system 4 based on causal replay verification, the system specifically comprising: The data encapsulation module 401 is used to respond to the diagnostic commands sent by the interactive terminal, obtain the abnormal logs, session traces and operating environment fingerprints within the target time window through the two-way authenticated monitoring interface, and encapsulate them into abnormal diagnostic data. The change determination module 402 is used to obtain a candidate change set based on the anomaly diagnosis data and the corresponding time range of commit differences, dependency lock files and source mapping files in the code repository. The causal association module 403 is used to generate an abnormal triggering operation sequence based on the session trajectory, determine the abnormal target environment and control environment based on the abnormal log and the runtime environment fingerprint, and construct an abnormal causal association graph based on the candidate change set, the abnormal triggering operation sequence, and the environmental differences between the abnormal target environment and the control environment. Patch generation module 404 is used to determine root cause candidates along the abnormal cause-effect graph and generate candidate repair patches for the root cause candidates. The patch verification module 405 is used to deploy candidate repair patches to the isolation replay sandboxes corresponding to the abnormal target environment and the control environment, and replay the abnormal triggering operation sequence to obtain patch verification results. The patch return module 406 is used to determine the patch verification confidence level based on the patch verification results and the correlation strength of the root cause candidates, and output the target repair patch, the corresponding abnormal causal relationship graph, and the rollback application instruction to the interactive terminal when the patch verification confidence level reaches a preset threshold.

[0110] It is understandable that, such as Figure 1 The content of the front-end anomaly self-healing method embodiment based on causal replay verification shown is applicable to the front-end anomaly self-healing system embodiment based on causal replay verification. The specific functions implemented by the front-end anomaly self-healing system embodiment based on causal replay verification are the same as those shown in the example. Figure 1 The front-end anomaly self-healing method based on causal replay verification shown is the same as the embodiment described above, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the front-end anomaly self-healing method embodiment based on causal replay verification shown are also the same.

[0111] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0112] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0113] Reference Figure 5 The present invention also provides a computer device 5, including: a memory 502 and a processor 501, and a computer program 503 stored on the memory 502. When the computer program 503 is executed on the processor 501, it implements the front-end anomaly self-healing method based on causal replay verification as described in any of the above methods.

[0114] The computer device 5 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 5 may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art will understand that... Figure 5 The computer device 5 is merely an example and does not constitute a limitation on the computer device 5. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0115] The processor 501 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0116] In some embodiments, the memory 502 may be an internal storage unit of the computer device 5, such as a hard disk or memory of the computer device 5. In other embodiments, the memory 502 may be an external storage device of the computer device 5, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 5. Further, the memory 502 may include both internal and external storage units of the computer device 5. The memory 502 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 502 can also be used to temporarily store data that has been output or will be output.

[0117] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the front-end anomaly self-healing method based on causal replay verification as described in any of the above methods.

[0118] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0119] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0120] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0121] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A front-end anomaly self-healing method based on causal replay verification, characterized in that, The method specifically includes: In response to diagnostic commands sent by the interactive terminal, the monitoring interface with two-way authentication obtains the abnormal logs, session traces and runtime environment fingerprints within the target time window and encapsulates them into abnormal diagnostic data. Based on the anomaly diagnostic data, the commit differences, dependency lock files, and source mapping files in the corresponding time range in the code repository are associated to obtain a candidate change set; An abnormal triggering operation sequence is generated based on the session trajectory. The abnormal target environment and control environment are determined based on the abnormal log and runtime environment fingerprint. An abnormal causal relationship graph is constructed based on the candidate change set, the abnormal triggering operation sequence, and the environmental differences between the abnormal target environment and the control environment. Candidate root causes are identified along the abnormal causal relationship graph, and candidate repair patches are generated for the candidate root causes. Deploy candidate patch to the isolation replay sandbox corresponding to the abnormal target environment and the control environment, and replay the abnormal triggering operation sequence to obtain patch verification results; Based on the patch verification results and the correlation strength of root cause candidates, the patch verification confidence level is determined. The target repair patch with a patch verification confidence level reaching a preset threshold, the corresponding abnormal causal relationship graph, and the rollback application instruction are output to the interactive terminal.

2. The method according to claim 1, characterized in that, The method, in response to diagnostic commands sent by the interactive terminal, obtains anomaly logs, session traces, and runtime environment fingerprints within the target time window through a two-way authenticated monitoring interface, and encapsulates them into anomaly diagnostic data, specifically including: Parse diagnostic commands to obtain project identifiers, anomaly filtering criteria, and target time windows; Two-way authentication is completed based on client certificates and monitoring interfaces, and access authorization corresponding to the project identifier is obtained; Based on access authorization, send an abnormal data query request to the monitoring interface, and obtain abnormal logs according to the abnormal filtering conditions and target time window; Obtain the session trajectory by associating it with the user identifier, session identifier, or link tracing identifier in the anomaly log; Extract browser information, operating system information, page address, network status, application build version and dependency versions from exception logs and session traces to generate runtime environment fingerprints; Configure the same diagnostic association identifier for exception logs, session traces, and runtime environment fingerprints, and encapsulate them as exception diagnostic data.

3. The method according to claim 1, characterized in that, The candidate change set is obtained by associating the anomaly diagnostic data with the corresponding time range of commit differences, dependency lock files, and source mapping files in the code repository, specifically including: Extract resource addresses, compressed code coordinates, anomaly timestamps, and application build identifiers from anomaly diagnostic data; The target build commit in the code repository is determined based on the application build identifier, and the code change range is determined based on the exception timestamp. Retrieve commit differences within the code change range and associate them with source file changes corresponding to the resource addresses; Read the dependency lock file corresponding to the target build commit to determine dependency version changes; Based on the application build identifier and resource address, obtain the source mapping file from the build artifact repository or monitoring platform, and use the source mapping file to map the compressed code coordinates to the source files and lines of code; A candidate change set is generated based on the mapping results of commit differences, dependency version changes, and source files and lines of code.

4. The method according to claim 1, characterized in that, The step of generating an anomaly triggering operation sequence based on the session trajectory specifically includes: Extract trajectory event records from the session trajectory. The trajectory event records include session identifier, occurrence time, event type, operation object location information, operation parameters, interface response status, and exception marker. Anomaly event records are identified based on anomaly markers, and the occurrence time of the anomaly event record is used as the backtracking endpoint to filter trajectory event records that have the same session identifier as the anomaly event record and are located within a preset backtracking period. Sort the selected trajectory event records according to the occurrence time, and delete adjacent duplicate trajectory event records; Based on the event type, operation object location information and operation parameters in the sorted trajectory event records, generate executable operation instructions, and generate waiting conditions corresponding to the executable operation instructions based on the interface response status; The executable operation instructions and waiting conditions are concatenated in the order of occurrence time of the trajectory event records corresponding to the executable operation instructions to generate an abnormal trigger operation sequence.

5. The method according to claim 1, characterized in that, The process of determining the abnormal target environment and the reference environment based on the abnormal logs and runtime environment fingerprints specifically includes: Extract the source environment instance identifier from the anomaly log, locate the corresponding target fingerprint record in the runtime environment fingerprint based on the source environment instance identifier, and determine the runtime environment represented by the target fingerprint record as the anomaly target environment; Based on the collection time of the target fingerprint record, other environmental fingerprint records that are not associated with abnormal logs within a preset time range are filtered out; By comparing the terminal type, operating system version, browser kernel version, application version, dependency version, and configuration items in other environmental fingerprint records with the target fingerprint record, the environmental differences are obtained; The operating environment characterized by the environmental fingerprint record with the fewest environmental differences is identified as the control environment.

6. The method according to claim 1, characterized in that, The construction of the anomaly causal relationship graph based on the candidate change set, the anomaly triggering operation sequence, and the environmental differences between the anomaly target environment and the control environment specifically includes: Associate the anomaly locations in the anomaly log with the candidate change set to generate change nodes; An operation node is generated based on the operation instructions, waiting conditions, and interface response status in the abnormal trigger operation sequence. Environment nodes are generated based on the environmental differences between the abnormal target environment and the control environment. Establish the first association edge based on the code call relationship, interface association relationship, and occurrence sequence between the change node and the operation node. Establish a second association edge based on the version dependency and configuration reference relationship between the change node and the environment node; The association strength is determined based on the temporal proximity, call count, and environmental difference matching of the first and second associated edges, resulting in an abnormal causal association graph.

7. The method according to claim 6, characterized in that, The process of identifying root cause candidates along the abnormal causal relationship graph and generating candidate repair patches for these root cause candidates specifically includes: The node in the abnormal cause-effect graph that corresponds to the abnormal log is identified as the abnormal starting node. Traverse backwards along the associated edges pointing to the starting node of the anomaly to obtain the change nodes and environment nodes that have a causal relationship with the starting node of the anomaly. The root cause correlation strength is determined based on the association paths, association strength, and path length of each change node and each environment node to the anomaly initiation node. Nodes whose root cause association strength reaches a preset screening threshold are identified as root cause candidates. Based on the code changes, dependency version information, or configuration differences corresponding to the root cause candidates, generate candidate fix patches.

8. The method according to claim 1, characterized in that, The step of deploying candidate patch repairs to the isolation replay sandboxes corresponding to the abnormal target environment and the control environment, and replaying the abnormal triggering operation sequence to obtain patch verification results, specifically includes: Based on the runtime environment fingerprints corresponding to the abnormal target environment and the control environment, create mutually isolated target environment replay sandboxes and control environment replay sandboxes respectively. The candidate patch is loaded into the application version in the target environment replay sandbox and the control environment replay sandbox respectively, and the dependency version, configuration items and terminal execution parameters that match the fingerprint of each runtime environment are injected. In the target environment replay sandbox and the control environment replay sandbox, the abnormal trigger operation sequence is replayed according to the operation time sequence, and the page status, interface response results and abnormal logs are collected respectively. The patch verification results are obtained by comparing the replay results in the target environment replay sandbox with the anomaly logs before patch deployment and the replay results in the control environment replay sandbox.

9. The method according to claim 1, characterized in that, The process of determining patch verification confidence based on patch verification results and the correlation strength of root cause candidates, and outputting the target repair patch with a patch verification confidence reaching a preset threshold, the corresponding anomaly causal relationship graph, and the rollback application instruction to the interactive terminal, specifically includes: Extract the anomaly elimination status, operation sequence execution completion status, interface response consistency, and comparison environment function retention status from the patch verification results; The patch verification score is determined based on the anomaly elimination status, the completion status of the operation sequence, the consistency of the interface response, and the functional retention status of the comparison environment. Obtain the association strength of the root cause candidates corresponding to the candidate repair patches, and determine the patch validation confidence by combining the patch validation score; Candidate patch repairs whose patch verification confidence reaches a preset threshold are identified as target patch repairs. Based on the target patch, generate a rollback application instruction that includes the patch identifier, applicable version, deployment scope, and rollback version, and output the target patch, the corresponding anomaly cause-effect graph, and the rollback application instruction to the interactive terminal.

10. A front-end anomaly self-healing system based on causal replay verification, characterized in that, The system specifically includes: The data encapsulation module is used to respond to diagnostic commands sent by the interactive terminal, obtain abnormal logs, session traces and runtime environment fingerprints within the target time window through a two-way authenticated monitoring interface, and encapsulate them into abnormal diagnostic data. The change determination module is used to obtain a candidate change set by associating commit differences, dependency lock files and source mapping files in the code repository within the corresponding time range based on anomaly diagnostic data. The causal association module is used to generate anomaly trigger operation sequences based on session trajectories, determine the anomaly target environment and control environment based on anomaly logs and runtime environment fingerprints, and construct anomaly causal association graph based on candidate change sets, anomaly trigger operation sequences, and environmental differences between the anomaly target environment and control environment. The patch generation module is used to identify root cause candidates along the abnormal causal relationship graph and generate candidate repair patches for the root cause candidates. The patch verification module is used to deploy candidate patch remediation to the isolation replay sandboxes corresponding to the abnormal target environment and the control environment, and replay the abnormal triggering operation sequence to obtain patch verification results; The patch return module is used to determine the patch verification confidence level based on the patch verification results and the correlation strength of root cause candidates, and output the target repair patch with the patch verification confidence level reaching the preset threshold, the corresponding abnormal causal relationship graph, and the rollback application instruction to the interactive terminal.

Images