Front-end State Abnormality Detection Method and System Based on Causal Chain

Abstract

The embodiments of this specification disclose a front-end state anomaly detection method and system based on causal chains. The method includes the following steps: Step S1: Identify the call relationships among event listeners, asynchronous tasks, and state change logic by parsing the source code, and construct an expected causal chain model; Step S2: During the application runtime, dynamically verify whether the actually occurring causal chain conforms to the expected model; wherein, in Step S1, the parsing of the source code is performed through techniques including but not limited to AST technology; in Step S2, the hijacking methods of key functions include but are not limited to the Proxy mechanism, function wrapping, and Hook technology. This application constructs an expected causal chain model and dynamically verifies the actual path during runtime, avoiding system inconsistencies caused by causal chain anomalies. Secondly, it uses an AI model to generate repair strategy suggestions, upgrading the inefficient troubleshooting process that traditionally relies on logs and breakpoint debugging to intelligent decision-making, significantly improving the repair efficiency.

Description

Technical Field

[0001] Multiple embodiments of this specification relate to the field of front - end state exception detection, and specifically to a method and system for front - end state exception detection based on a causal chain. Background Art

[0002] Front - end state management based on a causal chain is a method that emphasizes the causal relationship between operations, aiming to ensure a clear and consistent association between user interactions and the resulting state changes. In this method, each user action such as clicking a button, submitting a form, etc. is regarded as a "cause", and the corresponding application state changes such as data updates, page redrawing, etc. are the "effects" of this "cause". By establishing and maintaining this causal relationship, developers can more precisely control the behavior of the application, enabling each user interaction to cause the corresponding state update as expected. This approach emphasizes the importance of the causal relationship between operations to achieve predictable application behavior and simplify the debugging process. However, in the prior art, state management frameworks such as Vuex or Redux rely on developers to manually handle asynchronous logic, which makes the integrity of the causal chain largely depend on the code quality. Due to the lack of an automated verification mechanism, once there are network delays, failures, or code logic errors, it may lead to the breakage or invalidation of the causal chain, and thus lose the association between user actions and state changes. Therefore, it is necessary to study the detection and repair methods for the failure or breakage of the causal chain. Summary of the Invention

[0003] Multiple embodiments of this specification describe a method and system for front - end state exception detection based on a causal chain.

[0004] In a first aspect, embodiments of this specification provide a method for front - end state exception detection based on a causal chain, including the following steps:

[0005] Step S1: Static analysis, by parsing the source code to identify the call relationship between event listeners, asynchronous tasks, and state change logic, and constructing an expected causal chain model;

[0006] Step S2: During the operation of the application, dynamically verify whether the actual causal chain conforms to the expected model;

[0007] Among them, in step S1, the parsing of the source code is carried out through techniques including but not limited to AST technology;

[0008] Among them, in step S2, the hijacking methods of key functions include but are not limited to the Proxy mechanism, function wrapping, and Hook technology.

[0009] In a second aspect, embodiments of this specification provide a system for front - end state exception detection based on a causal chain, including:

[0010] Static Analysis and Modeling Module: By parsing the code, extract the key nodes of event listening, asynchronous tasks, and state changes, and construct a causal relationship graph between the nodes to form an expected causal chain model as the benchmark for subsequent dynamic verification;

[0011] Dynamic Monitoring and Verification Module: At runtime, hijack the code to record the actual paths of event triggering, asynchronous calls, and state changes in real-time, and detect anomalies by comparing with the expected causal chain model;

[0012] Fixing Module: Combine the rule engine and the AI model to locate the cause of the causal chain anomaly, generate a repair plan based on the policy library, and finally output executable repair suggestions;

[0013] Fault Tolerance and Rollback Module: When an irreversible anomaly is detected, restore the system to the nearest stable state through the snapshot rollback mechanism, support selecting rollback points according to time, version, or user behavior dimensions, and record the difference logs;

[0014] Data Storage Module: Persistently store the causal chain model versions, structured logs of anomaly events, repair strategy execution records, and system state snapshots, support fast query and analysis, and integrate into the existing monitoring system;

[0015] Alarm and Notification Module: According to the severity and impact scope of the anomaly, trigger notifications through a hierarchical strategy, support custom alarm rules, and generate periodic reports for the team to review;

[0016] Verification and Execution Module: Simulate the execution effect of the repair strategy in an isolated environment to ensure that the repair does not introduce new problems, and record the verification results to optimize subsequent strategy selection.

[0017] Thirdly, the embodiments of this specification provide an electronic device, including a processor and a memory;

[0018] The processor is connected to the memory;

[0019] The memory is used to store executable program code;

[0020] The processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory to be used to execute the method described in any of the above aspects.

[0021] Fourthly, the embodiments of this specification provide a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method described in any of the above aspects is implemented.

[0022] Fifthly, the embodiments of this specification provide a computer program product, including a computer program, and when the computer program is executed by a processor, the method described in any of the above aspects is implemented.

[0023] The beneficial effects brought by the technical solutions provided in some embodiments of this specification at least include:

[0024] 1. Actively discover causal logic loopholes and prevent breaks: By constructing an expected causal chain model through static code analysis and dynamically verifying the actual path at runtime, logically defective parts in the code can be identified in advance, avoiding system inconsistencies and unpredictabilities caused by broken causal chains, and significantly reducing development and maintenance costs;

[0025] 2. Comprehensively cover asynchronous operation management and reduce human errors: Through AST parsing and code hijacking technologies, automatically extract and model the association relationships between asynchronous tasks, events, and state nodes, record the asynchronous execution paths and results in real time, reduce the dependence on developers' manual handling of asynchronous logic, and reduce the risk of breaks caused by improper asynchronous management;

[0026] 3. Accurately locate the cause and accelerate problem fixing: Combine a rule engine and an AI model to quickly locate the cause of broken causal chains and generate suggestions for repair strategies, upgrading the inefficient troubleshooting process that traditionally relies on logs and breakpoint debugging to intelligent decision-making, and significantly improving the repair efficiency;

[0027] 4. Provide real-time fault tolerance and rollback to ensure system stability: Through causal chain snapshot storage and hierarchical degradation protocols, when a break or failure is detected, it can quickly roll back to the nearest stable state or degrade functions as needed, ensuring the availability of the core functions of the system and minimizing the risk of business interruption;

[0028] 5. Adapt to complex environments and microservice architectures: Achieve collaborative repair in microservice architectures through cross-service API notifications; Use a distributed database to store causal chain models and snapshots, support global consistency and high availability, and implement full-link tracing and management of causal chains in complex systems.

[0029] Other features and advantages of multiple embodiments of this specification will be further revealed in the following specific implementation manners and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] To more clearly illustrate the technical solutions in the embodiments of this specification, the following briefly introduces the drawings required in the embodiments. Obviously, the drawings in the following description are only some embodiments of this specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0031] Figure 1 It is a schematic diagram of causal chain integrity detection provided for the embodiments of this specification;

[0032] Figure 2Schematic diagram for constructing an expected causal chain model provided by the embodiments of this specification;

[0033] Figure 3 Schematic diagram for verifying the causal chain in the operation stage provided by the embodiments of this specification;

[0034] Figure 4 Schematic diagram for AI-assisted repair of the causal chain provided by the embodiments of this specification;

[0035] Figure 5 Schematic diagram of a front-end status anomaly detection system based on a causal chain provided by the embodiments of this specification;

[0036] Figure 6 Schematic diagram of an electronic device provided by the embodiments of this specification. Detailed implementation manners

[0037] The technical solutions of the embodiments of this specification will be explained and described below with reference to the accompanying drawings of the embodiments of this specification. However, the following embodiments are only the preferred embodiments of this specification, not all of them. Based on the embodiments in the implementation manners, other embodiments obtained by those skilled in the art without creative efforts all fall within the protection scope of this specification.

[0038] The terms "first", "second", "third", etc. in the specification, claims and the above-mentioned drawings of this specification are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices.

[0039] In the following description, terms such as "inner", "outer", "upper", "lower", "left", "right", etc. indicating orientation or positional relationship are only for the convenience of describing the embodiments and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be construed as a limitation of this specification.

[0040] The data involved in this application are all information and data authorized by users or fully authorized by all parties, and the collection of relevant data complies with the relevant laws, regulations and standards of relevant countries and regions.

[0041] Before introducing the technical solutions described in this specification, the application scenarios of the technical solutions and related technologies will be introduced.

[0042] A causal chain is a model or tool for describing the causal relationships between events. It explains the occurrence and development of a certain phenomenon through a series of causes and effects. In the field of software development, especially in front-end applications, the causal chain focuses on the direct association between user operations and changes in the application state. The state management method based on the causal chain can help developers understand and implement how to update the application state through a series of user operations such as clicking buttons and submitting forms. For example, Redux is a popular state management library that manages state changes through the concepts of actions and reducers. There are clear causal relationships between these actions and reducers. Pay attention to the causal relationships between user interactions and internal system events to better manage and optimize the state and behavior of front-end applications.

[0043] However, traditional frameworks only provide state management and cannot actively detect causal logic vulnerabilities. There may be phenomena such as the breakage or failure of the causal chain. The breakage or failure of the causal chain refers to the loss of the association between events such as user behavior and results such as state changes in a software system due to various reasons, and it is impossible to ensure that the system executes according to the expected logic. This situation may lead to system inconsistency and unpredictability, seriously affecting the user experience and system reliability.

[0044] Specific phenomena of the breakage or failure of the causal chain include: The user operation does not produce the expected effect. For example, after the user clicks a button, the expected state change does not occur, or an incorrect state change occurs; Asynchronous requests fail or are delayed. Network latency or server response timeouts result in the failure to correctly execute state updates that depend on these responses; Data inconsistency. Due to the breakage of the causal chain, data synchronization problems occur between different modules, resulting in inconsistent data within the system; Difficulty in tracing the root cause of the problem: The lack of effective logging or monitoring tools makes it difficult to locate the problem.

[0045] The reasons for the breakage or failure of the causal chain are as follows: Improper management of asynchronous operations: When processing asynchronous operations such as API requests, if there is no appropriate mechanism to ensure the successful completion of the request and perform necessary state updates based on the request result, it may lead to the breakage of the causal chain; Code logic defects: Logical errors, such as missing conditional branches and improper exception handling, may cause incorrect state changes not to be triggered for specific user behaviors; Memory leaks: If a long-running application has memory leaks, over time it may exhaust the available memory, resulting in the loss of historical causal chain data and affecting the consistency and traceability of the state; Incorrect binding of event listeners: In applications in a dynamic environment, if event listeners are not correctly bound or unbound, some important user interaction events may be missed, causing the breakage of the causal chain.

[0046] In response to these phenomena, it is generally necessary to manually handle asynchronous logic. For example, frameworks like Vuex / Redux require developers to manually handle asynchronous logic, which increases the risk of human error because the integrity of the causal chain completely depends on the code quality of developers and lacks an automated verification mechanism. In addition, currently, troubleshooting such problems mainly relies on logs and breakpoint debugging. This method is not only time-consuming but also inefficient, especially in complex asynchronous scenarios where it is more difficult to locate problems.

[0047] Therefore, first, it is necessary to study a method for detecting abnormal front-end states based on the causal chain. Please refer to the appendix Figure 1 , which is the system diagram of the causal chain integrity detection in this technology. The diagram shows the solutions in two stages. First, in the static analysis stage, the main purpose of this stage is to identify and understand the interaction relationships between various components by parsing the source code, clarify the call relationships between key elements, and help developers identify potential design flaws or logical errors that may cause problems in advance without running the program. In the program runtime tracing stage, the actual behavior of the program is monitored in real time to verify whether the actual causal chain that occurs is consistent with the data collected in the static analysis stage. If there is a deviation, it may mean that there is an abnormal situation that requires further investigation, so as to detect whether the causal chain fails or breaks during the program runtime.

[0048] In view of the fact that this application will involve some professional terms, therefore, the following will introduce these professional terms first.

[0049] Causal chain model: It refers to a logical structure that describes or predicts the behavior of a system by analyzing the causal relationships between various components within the system, used to identify how different parts of the system interact with each other and how these interactions affect the overall performance and stability of the system.

[0050] AI (Artificial Intelligence): It refers to the technology and methods that use computer systems to simulate and execute complex tasks that usually require human intelligence. In this application, AI analyzes a large amount of data generated during the runtime of the front-end application through algorithms and models, identifies abnormal patterns, and automatically proposes or implements repair strategies based on a pre-trained or real-time learning knowledge base to ensure that the application state meets the requirements of the expected causal chain model.

[0051] Confidence level and risk level: The confidence level refers to the judgment credibility of the AI model for the repair strategy, and the risk level indicates the level of negative impact that the repair strategy may bring. The risk assessment in AI repair draws on the logic of information security risk assessment.

[0052] Specifically, please refer to the appendix Figure 2 and Figure 3 , this specification first provides a method for detecting abnormal front-end states based on the causal chain, including the following steps:

[0053] Step S1: Static analysis. By parsing the source code, identify the call relationships among event listeners, asynchronous tasks, and state change logic, and construct an expected causal chain model.

[0054] Step S2: During the application runtime, dynamically verify whether the actual causal chain conforms to the expected model.

[0055] Among them, in Step S1, the steps of constructing the expected causal chain model include:

[0056] Step A1: Extract the key interaction nodes in the code through static code analysis to provide basic data for causal modeling, including two parts: AST parsing and key node extraction. The specific content is as follows:

[0057] AST parsing: For the front-end source code, use compilers such as Babel or TypeScript Compiler API to generate an Abstract Syntax Tree (AST), and combine plugins of ESLint or SonarJS to implement in-depth code analysis.

[0058] Key node extraction includes:

[0059] Event listener: Identify all event binding codes, such as addEventListener, onClick. For example: document.getElementById('btn').addEventListener('click', handler); The extracted information is event type click, target element btn, and callback function handler.

[0060] Asynchronous task: Include explicit and implicit asynchrony. Identify asynchronous function calls such as fetch, setTimeout, axios.get. Example: fetch(' / api / data').then(data => setState(data)); The extracted information is asynchronous type fetch, Uniform Resource Locator (URL) / api / data, and callback function setState.

[0061] State change: Identify state update logic such as dispatch in Redux, commit in Vuex, or direct state assignment. Example: store.dispatch({ type: 'SET_DATA', payload: data}); The extracted information is action type SET_DATA and trigger condition such as whether data is valid.

[0062] Step A2: Map the extracted nodes into a causal relationship graph and divide the levels according to the TRIZ method, which specifically includes the following steps:

[0063] Define the node types:

[0064] Event node: Represents user interaction or system events, such as click, submit;

[0065] Asynchronous node: Represents asynchronous operations, such as fetch, setTimeout;

[0066] State node: Represents state changes, such as SET_DATA, SET_LOADING;

[0067] Interface node: Reflects the mapping from state to interface, such as render, updateUI.

[0068] Define the edge types:

[0069] Trigger edge: Represents that an event triggers an asynchronous operation, such as click → fetch;

[0070] Dependency edge: Represents that the result of an asynchronous operation depends on a state change, such as fetch → SET_DATA;

[0071] Feedback edge: Represents that after a state change, it is fed back to the user interface, such as SET_DATA → render;

[0072] Hierarchical edge: Labels the causal chain level and the subordination relationship, such as the parent node of SET_DATA is fetch.

[0073] Construct the causal graph:

[0074] Directed acyclic graph (DAG): Ensure that the path is unique and there is no cycle;

[0075] Hierarchical annotation: Hierarchical annotation is the logical layering of the DAG, used to clarify the depth and priority of the causal chain, including annotating the direct cause and the root cause, and combining it with the defect analysis derivation of TRIZ;

[0076] AND / OR relationship: This part is the logical condition constraint between DAG nodes, used to describe the prerequisite conditions for causal triggering. In the AND relationship, multiple conditions must be met simultaneously, such as data being valid and the API being successful → SET_DATA. In the OR relationship, any condition being met can trigger, such as user login or API cache → display data.

[0077] Visualization:

[0078] Generate causal diagrams using Cytoscape.js or Mermaid, and label node types and edge relationships.

[0079] Step A3: Rule set verification and model optimization, which optimize the integrity of the causal chain model through static rules and dynamic models, specifically including:

[0080] Static rule verification: Use the ESLint plugin to check error handling and code specifications, verify type definitions through the TypeScript compiler, and perform static analysis on the code; Use graph analysis tools such as networkx to check the legitimacy, hierarchical relationships, loops, etc. of the DAG to achieve the verification of the model structure;

[0081] Dynamic model enhancement:

[0082] Causal Machine Learning (CML): Use an Interactive Regression Model (IRM) to analyze the code structure and discover implicit causal relationships in a data-driven manner. For example, infer the association between the timeout threshold of setTimeout and the state update delay through the IRM;

[0083] TRIZ causal chain analysis: Divide the causal chain into direct causes such as API failures and root causes such as server configuration errors; Mark critical drawbacks, such as the direct cause of the user not receiving notifications is the WebSocket disconnection;

[0084] Heinrich model extension: Add implicit risk nodes, predict potential risks and optimize the model path, such as network latency → timeout → state not updated;

[0085] Type system integration: Ensure that the state and data types meet expectations during dynamic execution, avoid implicit errors, and use typeguards in TypeScript to verify state conditions.

[0086] Step A4: Generate a structured model.

[0087] Output format: JSON / YAML, including nodes, edges, rules, hierarchical relationships, and a structured representation of the causal chain diagram.

[0088] Among them, in step S2, the verification steps for the causal chain include:

[0089] Step B1: Hijack key functions through code injection or proxy technology.

[0090] Among them, the hijacking targets include:

[0091] Event handlers: such as user interaction events, framework hooks;

[0092] Asynchronous functions: such as network requests, timers, Promise chains;

[0093] State change functions: such as dispatch in Redux, setState in React, and commit in state management libraries.

[0094] Among them, the hijacking methods include:

[0095] Proxy mechanism: By intercepting function calls, such as new Proxy(fn, handler), monitoring logic is inserted before and after the call to record parameters, return values, and timestamps.

[0096] Function wrapping: By rewriting functions, such as originalFn =...; fn = wrapper(originalFn), monitoring code is inserted before and after the execution of the original function.

[0097] Hook technology: In the Node.js or native environment, underlying functions such as socket and open are hijacked through LD_PRELOAD or dtrace to record the underlying operation paths.

[0098] Step B2: Record the actual execution path. The recorded content includes context information and key data. Set up a data structure and build a complete execution path chain, and convert the path into an actual DAG, where nodes represent operations and edges represent causal relationships. Among them, the recorded key data includes:

[0099] Event triggers, including: event types, such as click, keydown, submit; trigger time, a timestamp accurate to milliseconds; target element, the ID or path of the DOM element that triggers the event; user behavior context, such as click coordinates, input content, scroll position.

[0100] Asynchronous operations, including: asynchronous type, key parameters, execution results.

[0101] State changes, including: action type; state value, the state snapshot after the change, such as loading: true; trigger source, the associated previous function or event.

[0102] Among them, the recorded context information includes: network status, device information, environment snapshot, etc.

[0103] Among them, the data structure is a chained hash structure. Each record generates a unique hash value and is linked to the previous record to form an immutable chained structure, which can ensure that the recorded data has not been tampered with and provides a reliable basis for comparison.

[0104] Step B3: Set up a verification mechanism. Through the verification mechanism, the actual path is compared with the expected causal chain model in real time to detect whether the causal chain is broken or fails. This verification mechanism includes graph structure comparison and anomaly detection.

[0105] Among them, the graph structure comparison specifically includes:

[0106] Node matching: Check whether the actual node type is consistent with the expectation, such as whether fetch is marked as an asynchronous operation;

[0107] Edge matching: Verify whether the triggering relationship meets the expectation, such as whether fetch is triggered by a click event;

[0108] Condition constraint: Check whether the node execution conditions are met, such as whether SET_DATA is triggered after fetch is successful;

[0109] Order verification: Ensure that the node execution order conforms to the topological sorting of the DAG, such as fetch must be before SET_DATA.

[0110] Among them, the anomaly detection specifically includes:

[0111] Explicit anomalies, including: breakpoints, missing expected nodes in the actual path, such as fetch not triggering SET_DATA; unexpected nodes, undefined operations occur, such as an undeclared SET_ERROR state change in the model; incorrect order, the node execution order conflicts with the model, such as state update preceding the asynchronous operation.

[0112] Implicit anomalies, including: causal reasoning, analyzing the causal relationship of the path through causal machine learning (CML) to detect implicit breaks, such as fetch being successful but not triggering SET_DATA, possibly due to incorrect data format; pattern recognition, learning historical anomaly patterns through a graph neural network (GNN) to predict potential breakpoints, such as fetch returning 200 but not updating the status marked as an "unresolved data" anomaly.

[0113] On the other hand, when a causal chain anomaly is detected, this application proposes to use AI-assisted repair. Please refer to the appendix Figure 4 , which specifically includes the following steps:

[0114] Step C1: After detecting a causal chain anomaly, such as detecting an explicit or implicit anomaly in step B3, trigger the repair process and construct context features containing multi-dimensional data, including code paths, state snapshots, environmental data, and user behavior, etc. Subsequently, compress the high-dimensional features through PCA or hash encoding, and splice the compressed features into a unified input vector to provide comprehensive input for AI reasoning;

[0115] Step C2: Combine a rule engine such as Drools with a lightweight model such as an LSTM model to locate the root cause of the break and map it to the TRIZ defect classification to generate a repair template, providing a basis for generating repair strategies.

[0116] Step C3: Set up a repair policy library, set a risk level for each repair policy, use an AI model to select a repair policy, and evaluate its feasibility. Specifically, use a model based on TensorFlow.js, input the compressed feature vector of Step C1, output the policy probability, i.e., the confidence distribution, set a comprehensive credibility scoring formula, balance risk and confidence through the comprehensive scoring formula, and rank the policies by priority to ensure the feasibility and safety of the repair.

[0117] Specifically, the comprehensive credibility scoring formula is: Comprehensive score = Confidence × (1 - Risk level × α), where α is a constant between (0, 1), controlling the influence weight of the risk level on the score, and the value of α can be optimized and adjusted in real time according to historical data or cases.

[0118] Example: The repair policy library and the corresponding risk levels and confidences are as follows:

[0119] Policy 1: Automatic retry, confidence 0.8. If the LSTM predicts a high probability of continuous timeouts, the risk level is 1, which is a low risk, and only retry the operation.

[0120] Policy 2: Insert status update code, confidence 0.75. If the rule engine matches a missing status, the risk level is 2, which is a medium risk and involves code changes.

[0121] Policy 3: Trigger the circuit breaker mechanism, confidence 0.65, risk level 3, which is a high risk.

[0122] Step C4: Preview the repair policy in a sandbox environment to ensure its feasibility and safety, specifically including:

[0123] WebAssembly (Wasm) simulation: Simulate the execution path of the repaired code in the browser using Wasm, simulate the network environment and user behavior, check whether the critical path is closed, and record the response time after the repair.

[0124] AST transformation verification: Use Babel's AST toolchain to parse the original code, insert the repair code, and ensure that the patch has no syntax errors through ESLint or Babel's syntax validator.

[0125] Failure rollback mechanism: If the sandbox verification fails, roll back the policy priority, such as Policy 1 → Policy 2.

[0126] Step C5: Set the policy execution conditions, automatically or semi-automatically execute the repair according to the policy risk level, and support cross-service collaboration. In a microservices architecture, notify other services through APIs.

[0127] Example: The execution conditions include:

[0128] Automatic execution condition: When the confidence level > 0.8 and the risk level ≤ 2, execute directly. For example, Strategy 1: Retry the API request, such as retrying the fetch() 3 times, and Strategy 2: Dynamically insert code, such as setState('paid');

[0129] Manual confirmation for execution: When the confidence level < 0.8 or the risk level > 2, generate patch suggestions, highlight the code location through the VS Code plugin, and display the repair suggestions for developers to review and confirm.

[0130] Step C6: Evaluate the repair effect, including path comparison, confirm whether the break point of the causal chain is repaired, record the performance metrics after repair, collect user feedback, optimize the model and the root cause library, and then form a continuous improvement loop to support rollback and auditing.

[0131] Among them, the model optimization includes:

[0132] Online learning: Collect repair cases and only update the last layer of the model, such as the Dense layer, to avoid retraining;

[0133] Transfer learning: Extract repair cases from GitHub Issues, such as "State machine design defect" → "CircuitBreaker pattern", and improve the generalization ability through data augmentation.

[0134] Among them, the root cause library optimization includes:

[0135] New root cause classification: For example, classify "Fuse configuration missing" as "Architectural design defect" and associate it with the design pattern;

[0136] Rule library update: Add the newly discovered root cause to the rule engine, such as "API return format change" → "Switch to the alternate interface".

[0137] On the other hand, this application also sets up a fault tolerance mechanism for causal chain failure. When the causal chain, such as business processes, system states, or data dependencies, is abnormal or broken, it ensures system stability and user experience, while minimizing data loss and business interruption. Specifically, it includes:

[0138] Causal chain snapshot storage: Prevent data loss caused by memory leaks or program crashes, provide a reliable basis for rollback, use IndexedDB (front-end) or a distributed database (back-end) to persistently store the causal chain snapshot, record the status according to the timestamp and version number, support rollback to any historical valid state, force the generation of snapshots after key nodes such as state changes and asynchronous operation completions. Secondly, by monitoring metrics such as memory usage rate and API response time, anticipate possible failures and trigger snapshots in advance;

[0139] Failure Detection and Rollback: Detect logical breaks, parameter out-of-bounds, timeouts, etc., select the most recent valid snapshot to restore the system state, and record the rollback reason and state differences for subsequent analysis.

[0140] Degradation Protocol: Set a layering strategy to maintain the availability of core functions during failures and avoid user experience crashes.

[0141] Among them, the layering strategy includes:

[0142] The first layer: Non-critical asynchronous timeouts, the UI shows "loading" or basic information, and core operations are retained;

[0143] The second layer: Full-link failures of core APIs, the UI displays cached data such as historical records, and non-core modules are closed;

[0144] The third layer: The absence of critical states, the UI shows static content, and only basic queries are allowed.

[0145] On the other hand, this application also proposes a front-end state anomaly detection system based on the causal chain. Please refer to the appendix Figure 5 , and this system includes the following modules:

[0146] Static Analysis and Modeling Module: By parsing the code, extract key nodes such as event listeners, asynchronous tasks, and state changes, and construct a causal relationship graph between the nodes to form an expected causal chain model as a benchmark for subsequent dynamic verification;

[0147] Dynamic Monitoring and Verification Module: At runtime, hijack the code to record the actual paths of event triggers, asynchronous calls, and state changes in real time, and detect anomalies by comparing with the expected causal chain model;

[0148] Repair Module: Combine the rule engine and the AI model to locate the root cause of causal chain anomalies, generate repair solutions based on the policy library, and finally output executable repair suggestions;

[0149] Fault Tolerance and Rollback Module: When an irreversible anomaly is detected, restore the system to the most recent stable state through the snapshot rollback mechanism, or degrade the function according to the preset strategy, support selecting rollback points in dimensions of time, version, or user behavior, and record the difference logs;

[0150] Data Storage Module: Persistently store the causal chain model versions, structured logs of abnormal events, repair strategy execution records, and system state snapshots, support quick query and analysis, and integrate into the existing monitoring system;

[0151] Alarm and Notification Module: According to the severity and impact scope of the anomaly, trigger notifications through a grading strategy, support custom alarm rules, and generate periodic reports for the team to review;

[0152] Verification and Execution Module: Simulate the execution effect of the repair strategy in an isolated environment to ensure that the repair does not introduce new problems, and record the verification results to optimize subsequent strategy selection.

[0153] On the other hand, please refer to the appendix Figure 6 FIG. is a structural diagram of an electronic device provided by an embodiment of the present specification. The electronic device may include: at least one processor, at least one network interface, a user interface, a memory, and at least one communication bus. Among them, the communication bus can be used to realize the connection and communication of the above-mentioned components. Among them, the optional user interface may further include a standard wired interface and a wireless interface. Among them, the network interface may include, but is not limited to, a Bluetooth module, an NFC module, a Wi-Fi module, etc. Among them, the processor may include one or more processing cores. The processor uses various interfaces and lines to connect various parts within the entire electronic device, and by running or executing instructions, programs, code sets, or instruction sets stored in the memory, and by calling data stored in the memory, it executes various functions of the routing device and processes data. Among them, the processor may be implemented in at least one hardware form of a DSP, an FPGA, or a PLA. The processor may integrate one or several combinations of a CPU, a GPU, and a modem, etc. Among them, the CPU mainly processes the operating system, the user interface, and application programs, etc.; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; in the present application, the processor can efficiently process high-computation tasks such as static analysis (AST parsing, DAG construction), dynamic monitoring (hijacking functions, real-time recording), and AI-assisted repair (LSTM inference, CML model); the modem is used to process wireless communication.

[0154] It can be understood that the above-mentioned modem may not be integrated into the processor and may be implemented separately by a single chip. Among them, the memory may include RAM and ROM. Optionally, the memory includes a non-transitory computer-readable medium. The memory can be used to store instructions, programs, codes, code sets, or instruction sets. The memory may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for at least one function, instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store the data involved in the above-mentioned various method embodiments. The memory may optionally also be at least one storage device located far from the aforementioned processor. The memory as a computer storage medium may include an operating system, a network communication module, a user interface module, and application programs. The processor may be used to call the application programs stored in the memory and execute the methods in the above-mentioned multiple embodiments. In the present application, the memory can meet the storage requirements of code parsing, causal chain model, execution path recording (chain hash structure), and repair strategy library, and support the persistence (IndexedDB) and rollback mechanism of causal chain snapshots.

[0155] The embodiments of this specification also provide a computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions run on a computer or a processor, the computer or the processor is caused to execute multiple steps in the above embodiments. If each component module of the above electronic device is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in the computer-readable storage medium.

[0156] The embodiments of this specification also provide a computer program product, including a computer program. When the computer program is executed by a processor, multiple steps in the above embodiments are implemented.

[0157] Without conflict, the technical features in this embodiment and the implementation solutions can be combined arbitrarily.

[0158] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes multiple computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this specification are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or a wireless manner (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrating multiple available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a Digital Versatile Disc (DVD)), or a semiconductor medium (for example, a Solid State Disk (SSD)), etc.

[0159] When implemented through hardware or firmware, the foregoing method flow is programmed into a hardware circuit to obtain a corresponding hardware circuit structure and implement corresponding functions. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by a user's programming of the device. A designer can program a digital system "integrated" on a single PLD by himself without asking a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a hardware description language (HDL), and there is not only one kind of HDL, but many kinds. Those skilled in the art should also be clear that as long as the method flow is slightly logically programmed with the above-mentioned several hardware description languages and programmed into an integrated circuit, it is easy to obtain a hardware circuit that implements the logic method flow.

Claims

1. A method for detecting abnormal front-end states based on causal chains, characterized in that, It includes the following steps: Step S1: In the static analysis phase, identify the call relationships among event listeners, asynchronous tasks, and state change logic by parsing the source code, and construct an expected causal chain model; Step S2: During the application runtime, hijack critical functions and dynamically verify and compare the actual causal chain with the expected causal chain model; Among them, in Step S1, the parsing method of the source code includes AST technology; Among them, in Step S2, the hijacking methods of critical functions include the Proxy mechanism, function wrapping, and Hook technology; In the said Step S1, the steps for constructing the expected causal chain model include: Step A1: Extract key interaction nodes in the code through static code analysis to provide basic data for causal modeling; Step A2: Map the extracted nodes into a causal relationship graph and divide the levels according to the TRIZ method; Step A3: Rule set verification and model optimization to optimize the integrity of the causal chain model through static rules and dynamic models; Step A4: Generate the optimized causal chain model; In the said Step S2, the steps for verifying the causal chain include: Step B1: Hijack critical functions through code injection; Step B2: Record the actual execution path. The recorded content includes context information and key data. Set up a data structure and construct a complete execution path chain, and convert the path into an actual directed acyclic graph; Step B3: Set up a verification mechanism to compare the actual directed acyclic graph with the expected causal chain model in real time through the verification mechanism.

2. The front-end state anomaly detection method based on the causal chain according to claim 1, wherein In the said Step B3, the verification mechanism includes graph structure comparison and anomaly detection; Among them, the graph structure comparison includes: node matching, edge matching, conditional constraints, and order verification; Among them, anomaly detection specifically includes: explicit anomalies and implicit anomalies.

3. The front-end state anomaly detection method based on the causal chain according to claim 2, characterized in that This front-end state anomaly detection method based on the causal chain further includes: After detecting a causal chain anomaly through the said Step S2, perform AI-assisted repair; The steps of the said AI-assisted repair include: Step C1: After detecting a causal chain anomaly, trigger a repair process, construct context features containing multi-dimensional data, and provide comprehensive input for AI model reasoning; Step C2: Combine the rule engine with a lightweight model to locate the root cause of the break and map it to the TRIZ defect classification to generate a repair template, providing a basis for generating repair strategies; Step C3: Set up a repair strategy library, set a risk level for each repair strategy, and use the AI model to select the corresponding repair strategy; Step C4: Preview the repair strategy in a sandbox environment to verify its feasibility and security; Step C5: Set up strategy execution conditions, execute the repair according to the strategy risk level, and support cross-service collaboration. In a microservices architecture, notify other services through APIs; Step C6: Evaluate the repair effect, collect user feedback, optimize the AI model and the root cause library to form a continuous improvement loop, and support rollback and auditing.

4. The front-end state anomaly detection method based on a causal chain according to claim 3, wherein, This front-end state anomaly detection method based on the causal chain further includes a fault tolerance mechanism for causal chain failures; The said fault tolerance mechanism includes: Causal Chain Snapshot Storage: Prevent data loss caused by memory leaks and program crashes, provide a reliable basis for rollback, persistently store causal chain snapshots, record states by timestamp and version number, and support rollback to any valid historical state; Failure Detection and Rollback: When logical breaks, parameter out-of-bounds, or timeouts are detected, select the most recent valid snapshot to restore the system state, record the rollback reason and state differences for subsequent analysis; Degradation Protocol: Set a hierarchical strategy to maintain the availability of core functions during failures and avoid user experience crashes.

5. A front-end state anomaly detection system based on a causal chain, characterized in that, Including: Static Analysis and Modeling Module: By parsing the code, extract key nodes for event listening, asynchronous tasks, and state changes, and construct a causal relationship graph between the nodes to form an expected causal chain model as a benchmark for subsequent dynamic verification; Dynamic Monitoring and Verification Module: During runtime, hijack the code in real-time to record the actual paths of event triggers, asynchronous calls, and state changes, and detect anomalies by comparing with the expected causal chain model; Repair Module: Combine the rule engine and AI model to locate the cause of causal chain anomalies, generate repair solutions based on the policy library, and finally output executable repair suggestions; Fault Tolerance and Rollback Module: When an irreversible anomaly is detected, restore the system to the most recent stable state through the snapshot rollback mechanism, support selecting rollback points according to time, version, or user behavior dimensions, and record the difference logs; Data Storage Module: Persistently store causal chain model versions, structured logs of abnormal events, repair strategy execution records, and system state snapshots, support fast query and analysis, and integrate into the existing monitoring system; Alarm and Notification Module: According to the severity and impact scope of the anomaly, trigger notifications through a hierarchical strategy, support custom alarm rules, and generate periodic reports for the team to review; Verification and Execution Module: Simulate the execution effect of the repair strategy in an isolated environment to ensure that the repair does not introduce new problems, and record the verification results to optimize subsequent strategy selection; The steps for constructing the expected causal chain model include: Step A1: Extract key interaction nodes in the code through static code analysis to provide basic data for causal modeling; Step A2: Map the extracted nodes to a causal relationship graph and divide the levels according to the TRIZ method; Step A3: Rule set verification and model optimization, optimize the integrity of the causal chain model through static rules and dynamic models; Step A4: Generate the optimized causal chain model; The steps for verifying the causal chain include: Step B1: Hijack key functions through code injection; Step B2: Record the actual execution path, the recorded content includes context information and key data, set up a data structure and construct a complete execution path chain, and convert the path into an actual directed acyclic graph; Step B3: Set up a verification mechanism to compare the actual directed acyclic graph with the expected causal chain model in real-time through the verification mechanism.

6. An electronic device, characterized in that, Including a processor and a memory; The processor is connected to the memory; The memory is used to store executable program code; The processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the method according to any one of claims 1-4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1-4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1-4.

Images