Causal chain-based front-end state anomaly detection method and system

Abstract

The embodiment of the invention discloses a causal chain-based front-end state anomaly detection method and system. The method comprises the following steps: S1, identifying a calling relation among an event monitor, an asynchronous task and a state change logic by analyzing a source code, and constructing an expected causal chain model; s2, dynamically verifying whether the actually occurring causal chain conforms to an expected model or not during the application running period; wherein in the step S1, the analysis of the source code comprises but is not limited to an AST technology; in the step S2, the hijacking mode of the key function comprises but is not limited to a Proxy mechanism, function packaging and a Hook technology. According to the method, the expected causal chain model is constructed, the actual path is dynamically verified during operation, system inconsistency caused by causal chain abnormity is avoided, the AI model is utilized to generate the repair strategy suggestions, a traditional low-efficiency troubleshooting process depending on logs and breakpoint debugging is upgraded to intelligent decision, and the repair efficiency is remarkably improved.

Description

Technical Field

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

[0002] Front-end state management based on causal chain is a method that emphasizes the causal relationship between operations, aiming to ensure a clear and consistent association between user interaction and the state changes it causes. In this method, each user behavior such as clicking a button, submitting a form, etc. is regarded as a "cause", and the corresponding application state changes such as data update, page redraw, etc. are the "effects" of this "cause". By establishing and maintaining this causal relationship, developers can control the behavior of the application more accurately, so that each user interaction can cause the corresponding state update as expected. This method emphasizes the importance of causal relationships between operations to achieve predictable application behavior and simplify the debugging process. However, in the existing technology, 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 quality of the code. Due to the lack of an automated verification mechanism, once a network delay, failure, or code logic error occurs, the causal chain may be broken or invalidated, and the association between user behavior and state changes may be lost. Therefore, it is necessary to study the detection and repair methods of causal chain failure or breakage. Summary of the invention

[0003] Multiple embodiments of this specification describe a front-end status anomaly detection method or system based on a causal chain.

[0004] In a first aspect, the embodiments of this specification provide a front-end state abnormality detection method based on a causal chain, comprising the following steps: Step S1: Static analysis, by parsing the source code to identify the calling relationship between event listeners, asynchronous tasks and state change logic, and build an expected causal chain model; Step S2: During the application operation, dynamically verify whether the actual causal chain conforms to the expected model; Wherein, in step S1, the source code is parsed by, including but not limited to, AST technology; Among them, in step S2, the hijacking methods of key functions include but are not limited to Proxy mechanism, function packaging and Hook technology.

[0005] In a second aspect, the embodiment of this specification provides a front-end state anomaly detection system based on a causal chain, including: Static analysis and modeling module: By parsing the code, it extracts key nodes of event monitoring, asynchronous tasks, and state changes, and constructs a causal relationship diagram between nodes to form an expected causal chain model as a benchmark for subsequent dynamic verification; Dynamic monitoring and verification module: records the actual path of event triggering, asynchronous calls, and state changes in real time through code hijacking at runtime, and detects anomalies by comparing with the expected causal chain model; Repair module: Combines the rule engine and AI model to locate the cause of causal chain anomalies, generates repair plans based on the policy library, and finally outputs executable repair suggestions; Fault tolerance and rollback module: When an irreversible anomaly is detected, the system is restored to the most recent stable state through a snapshot rollback mechanism. It supports selecting a rollback point by time, version, or user behavior, and records a difference log. Data storage module: persistently stores causal chain model versions, structured logs of abnormal events, repair strategy execution records, and system status snapshots, supports fast query and analysis, and is integrated into existing monitoring systems; Alarm and notification module: triggers notifications through grading strategies based on the severity and impact of the anomaly, supports custom alarm rules, and generates periodic reports for team review; Verification and execution module: simulates the execution effect of the repair strategy in an isolated environment to ensure that the repair will not introduce new problems, and records the verification results to optimize subsequent strategy selection.

[0006] In a third aspect, an embodiment of this specification provides an electronic device, 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 a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the method described in any one of the above aspects.

[0007] In a fourth aspect, an embodiment of the present specification provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in any of the above aspects.

[0008] In a fifth aspect, an embodiment of this specification provides a computer program product, including a computer program, which implements the method described in any of the above aspects when executed by a processor.

[0009] The beneficial effects brought by the technical solutions provided by some embodiments of this specification include at least: 1. Actively discover causal logic loopholes and prevent breaks: Build an expected causal chain model through static code analysis, and dynamically verify the actual path at runtime, identify logical defects in the code in advance, avoid system inconsistency and unpredictability caused by causal chain breaks, and significantly reduce development and maintenance costs; 2. Comprehensively cover asynchronous operation management and reduce human errors: Through AST parsing and code hijacking technology, automatically extract and model the relationship between asynchronous tasks and events and state nodes, record asynchronous execution paths and results in real time, reduce the reliance on developers to manually handle asynchronous logic, and reduce the risk of breakage caused by improper asynchronous management; 3. Accurately locate the cause and accelerate problem repair: Combine the rule engine and AI model to quickly locate the cause of the causal chain break and generate repair strategy suggestions, upgrading the traditional inefficient troubleshooting process that relies on logs and breakpoint debugging to intelligent decision-making, significantly improving repair efficiency; 4. Real-time fault tolerance and rollback to ensure system stability: Through causal chain snapshot storage and hierarchical degradation protocol, when a break or failure is detected, it can quickly roll back to the most recent stable state or downgrade functions on demand to ensure the availability of core system functions and minimize the risk of business interruption; 5. Adapt to complex environments and microservice architectures: Implement collaborative repair in microservice architectures through cross-service API notifications; use distributed databases to store causal chain models and snapshots, support global consistency and high availability, and implement full-link tracking and management of causal chains in complex systems.

[0010] Other features and advantages of the various embodiments of the present specification will be further disclosed in the following detailed description and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of this specification, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0012] Figure 1 A schematic diagram of causal chain integrity detection provided in an embodiment of this specification; Figure 2 A schematic diagram of constructing an expected causal chain model provided in an embodiment of this specification; Figure 3 A schematic diagram of the cause-effect chain of the verification operation phase provided in the embodiment of this specification; Figure 4 A schematic diagram of the AI-assisted repair causal chain provided in the embodiments of this specification; Figure 5A schematic diagram of a front-end state anomaly detection system based on a causal chain provided in an embodiment of this specification; Figure 6 A schematic diagram of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0013] The following is an explanation and description of the technical solutions of the embodiments of this specification in conjunction with the drawings of the embodiments of this specification, but the following embodiments are only preferred embodiments of this specification, not all. Based on the embodiments in the implementation mode, other embodiments obtained by those skilled in the art without creative work are all within the scope of protection of this specification.

[0014] The terms "first", "second", "third", etc. in the description and claims of this specification and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. 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 includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices.

[0015] In the following description, terms such as "inside", "outside", "up", "down", "left", "right", etc. that indicate directions or positional relationships are only used to facilitate the description of the embodiments and simplify the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore should not be understood as a limitation of this specification.

[0016] The data involved in this application are all information and data authorized by the user 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.

[0017] Before describing the technical solution in this specification, an introduction is given to the application scenarios and related technologies of the technical solution.

[0018] A causal chain is a model or tool that describes the causal relationship between events. It explains the occurrence and development of a 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 connection between user operations and application state changes. 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 is a clear causal relationship between these actions and reducers. It focuses on the causal relationship between user interactions and internal system events to better manage and optimize the state and behavior of front-end applications.

[0019] However, traditional frameworks only provide state management and cannot proactively discover causal logic vulnerabilities, which may lead to causal chain breaks or failures. Causal chain breaks or failures refer to the situation in which, due to various reasons, the association between events such as user behavior and results such as state changes is lost in the software system, making it impossible to ensure that the system executes according to the expected logic. This situation may lead to inconsistency and unpredictability in the system, seriously affecting user experience and system reliability.

[0020] Specific phenomena of causal chain breakage or failure include: user operations do not produce the expected effects, for example, after the user clicks a button, the expected state change does not occur, or an incorrect state change occurs; asynchronous request failure or delay, network delay or server response timeout, resulting in state updates that rely on these responses not being executed correctly; data inconsistency, due to the break in 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.

[0021] The reasons that lead to the break or failure of the causal chain are: 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 make necessary status updates based on the request results, the causal chain may be broken; code logic defects: logical errors, such as omitted conditional branches, improper exception handling, etc., may result in specific user behaviors not triggering the correct state changes; memory leaks: if long-running applications have memory leaks, they may exhaust the available memory over time, resulting in the loss of historical causal chain data, affecting the consistency and traceability of the state; event listeners are not bound correctly: in applications in dynamic environments, if event listeners are not bound or unbound correctly, some important user interaction events may be missed, causing the causal chain to break.

[0022] To address these phenomena, it is generally necessary to manually handle asynchronous logic. For example, the Vuex / Redux framework requires developers to manually handle asynchronous logic, which increases the risk of human error because the integrity of the causal chain depends entirely on the quality of the developer's code and lacks an automated verification mechanism. In addition, the current troubleshooting of such problems mainly relies on logs and breakpoint debugging, which is not only time-consuming but also inefficient, especially in complex asynchronous scenarios where it is more difficult to locate problems.

[0023] To this end, we first need to study the front-end state anomaly detection method based on the causal chain. Figure 1 , is a system diagram of the causal chain integrity detection of this technology. The figure shows the scheme in two stages. First, in the static analysis stage, the main purpose of this stage is to identify and understand the interaction relationship between various components by parsing the source code, and to clarify the calling relationship between key elements. Without running the program, it helps developers to identify design defects or logical errors that may cause problems in advance. In the program runtime tracking stage, the actual behavior of the program is monitored in real time to verify whether the actual causal chain 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 and further investigation is needed to detect whether the causal chain is invalid or broken when the program is running.

[0024] Since this application involves some professional terms, these professional terms will be introduced below.

[0025] Causal chain model: refers to a logical structure that describes or predicts the behavior of a system by analyzing the causal relationship between the various components within the system. It is 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.

[0026] AI (Artificial Intelligence): 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 uses algorithms and models to analyze large amounts of data generated when front-end applications are running, identify abnormal patterns, and automatically propose or implement repair strategies based on pre-trained or real-time learned knowledge bases, thereby ensuring that the application status meets the requirements of the expected causal chain model.

[0027] Confidence and risk level: Confidence refers to the credibility of the AI ​​model's judgment on 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.

[0028] For details, please refer to the attached Figure 2 and Figure 3 , this specification first provides a front-end state anomaly detection method based on a causal chain, including the following steps: Step S1: Static analysis, by parsing the source code to identify the calling relationship between event listeners, asynchronous tasks and state change logic, and build an expected causal chain model; Step S2: During application operation, dynamically verify whether the actual causal chain conforms to the expected model.

[0029] Among them, in step S1, the steps of 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, including AST parsing and key node extraction. The specific contents are as follows: AST parsing: For the front-end source code, use the Babel or TypeScript Compiler API compiler to generate an abstract syntax tree (AST), combined with ESLint or SonarJS plug-ins to achieve in-depth code analysis; Key node extraction includes: Event listener: Identify all event binding codes, such as addEventListener, onClick, for example: document.getElementById('btn').addEventListener('click', handler); extract information as event type click, target element btn, callback function handler; Asynchronous tasks: including explicit asynchrony and implicit asynchrony, identifying asynchronous function calls such as fetch, setTimeout, axios.get, example: fetch(' / api / data').then(data =>setState(data)), extracting information as asynchronous type fetch, uniform resource locator (URL) / api / data, callback function setState; State change: Identify state update logic such as Redux's dispatch, Vuex's commit, or direct state assignment. For example, store.dispatch({ type: 'SET_DATA', payload: data}) extracts information such as action type SET_DATA and trigger conditions such as whether data is valid.

[0030] Step A2: Map the extracted nodes into a cause-effect relationship diagram and divide the levels according to the TRIZ method, which specifically includes the following steps: Define the node type: Event node: represents user interaction or system events, such as click and submit; Asynchronous node: represents asynchronous operations, such as fetch and setTimeout; Status node: indicates status change, such as SET_DATA, SET_LOADING; Interface node: reflects the mapping of state to interface, such as render and updateUI.

[0031] Define the edge type: Trigger edge: indicates that an event triggers an asynchronous operation, such as click → fetch; Dependency edge: indicates that the result of an asynchronous operation depends on a state change, such as fetch → SET_DATA; Feedback edge: indicates feedback to the user interface after the state change, such as SET_DATA → render; Hierarchical edge: annotates the causal chain hierarchy and subordinate relationships, such as the parent node of SET_DATA is fetch.

[0032] Constructing a cause-effect diagram: Directed Acyclic Graph (DAG): ensures that the path is unique and has no cycles; Hierarchical annotation: Hierarchical annotation is the logical layering of DAG, which is used to clarify the depth and priority of the cause-effect chain, including the annotation of direct causes and root causes, and combined with TRIZ defect analysis derivation; AND / OR relationship: This part is the logical condition constraint between DAG nodes, which is used to describe the prerequisites for causal triggering. In the AND relationship, multiple conditions must be met at the same time, such as data is valid and API is successful → SET_DATA. In the OR relationship, any condition can be met to trigger, such as user login or API cache → display data.

[0033] Visualization: Use Cytoscape.js or Mermaid to generate a causal graph, annotating node types and edge relationships.

[0034] Step A3: Rule set verification and model optimization, optimizing the integrity of the causal chain model through static rules and dynamic models, including: Static rule verification: Use the ESLint plug-in 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 legality of DAG, hierarchical relationships, loops, etc. to verify the model structure; Dynamic Model Enhancement: Causal Machine Learning (CML): Use the Interactive Regression Model (IRM) to analyze code structure and discover implicit causal relationships in a data-driven way, such as inferring the association between the timeout threshold of setTimeout and the state update delay through IRM; TRIZ causal chain analysis: Divide the causal chain into direct causes such as API failure and root causes such as server configuration errors; mark key shortcomings, such as the direct cause of the user not receiving the notification is the WebSocket disconnection; Heinrich model extension: add implicit risk nodes to predict potential risks and optimize model paths, such as network delay → timeout → status not updated; Type system integration: Ensure that states and data types meet expectations during dynamic execution, avoid implicit errors, and use TypeScript’s typeguard to verify state conditions.

[0035] Step A4: Generate a structured model.

[0036] Output format: JSON / YAML, including nodes, edges, rules, hierarchical relationships, and structured representation of causal chain graphs.

[0037] In step S2, the verification step of the causal chain includes: Step B1: Hijack key functions through code injection or proxy technology.

[0038] Among them, the hijacking targets include: Event handlers: such as user interaction events and framework hooks; Asynchronous functions: such as network requests, timers, and Promise chains; State change function: such as Redux's dispatch, React's setState, and state management library's commit.

[0039] Among them, the hijacking methods include: 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; Function wrapping: By rewriting the function, such as originalFn = ...; fn = wrapper(originalFn), the monitoring code is inserted before and after the original function is executed; Hook technology: In Node.js or native environment, hijack the underlying functions such as socket and open through LD_PRELOAD or dtrace to record the underlying operation path.

[0040] Step B2: Record the actual execution path. The record content contains context information and key data. Set up the data structure and build a complete execution path chain. Convert the path into an actual DAG. Nodes represent operations and edges represent causal relationships.

[0041] Among them, the key data recorded include: Event triggering, including: event type, such as click, keydown, submit; triggering time, timestamp accurate to milliseconds; target element, DOM element ID or path that triggers the event; user behavior context, such as click coordinates, input content, scroll position; Asynchronous operations, including: asynchronous type, key parameters, and execution results.

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

[0043] The recorded context information includes: network status, device information, environment snapshot, etc.

[0044] Among them, the data structure is a chain hash structure. Each record generates a unique hash value and links to the previous record to form an unalterable chain structure. This can ensure that the recorded data has not been tampered with and provide a reliable basis for comparison.

[0045] Step B3: Set up a verification mechanism to compare the actual path with the expected causal chain model in real time to detect whether the causal chain is broken or invalid. The verification mechanism includes graph structure comparison and anomaly detection.

[0046] Among them, the graph structure comparison specifically includes: Node matching: Check whether the actual node type is consistent with the expected one, such as whether fetch is marked as an asynchronous operation; Edge matching: Verify whether the trigger relationship is as expected, such as whether fetch is triggered by a click event; Conditional constraints: Check whether the node execution conditions are met, such as whether SET_DATA is triggered after a successful fetch; Sequential verification: Ensure that the node execution order conforms to the topological sorting of the DAG, such as fetch must be before SET_DATA.

[0047] Among them, anomaly detection specifically includes: Explicit exceptions include: breakpoints, the actual path lacks expected nodes, such as fetch not triggering SET_DATA; unexpected nodes, undefined operations, such as SET_ERROR state changes that are not declared in the model; sequence errors, the node execution order conflicts with the model, such as state updates precede asynchronous operations.

[0048] Implicit anomalies include: causal reasoning, analyzing the causal relationship of the path through causal machine learning (CML) to detect implicit breaks, such as fetch succeeds but SET_DATA is not triggered, which may be due to incorrect data format; pattern recognition, learning historical abnormal patterns through graph neural network (GNN) to predict potential breakpoints, such as fetch returns 200 but does not update the status mark as "data not parsed" anomaly.

[0049] On the other hand, when an abnormality in the causal chain is detected, this application proposes to use AI to assist in repair. Please refer to the attached Figure 4 , specifically including the following steps: Step C1: After detecting an anomaly in the causal chain, such as an explicit or implicit anomaly in step B3, the repair process is triggered and context features containing multi-dimensional data are constructed, including code paths, state snapshots, environmental data, and user behaviors. The high-dimensional features are then compressed through PCA or hash coding, and the compressed features are spliced ​​into a unified input vector to provide comprehensive input for AI reasoning; Step C2: Combine rule engines such as Drools with lightweight models such as LSTM models to locate the root cause of the fracture and map it to TRIZ defect classification to generate a repair template, providing a basis for repair strategy generation.

[0050] Step C3: Set up a repair strategy library and set a risk level for each repair strategy. Use the AI ​​model to select the repair strategy and evaluate its feasibility. Specifically, use a model based on TensorFlow.js, input the compressed feature vector of step C1, output the strategy probability, i.e., the confidence distribution, set a credibility comprehensive scoring formula, balance the risk and confidence through the comprehensive scoring formula, prioritize the strategies, and ensure the feasibility and safety of the repair.

[0051] Specifically, the formula for the comprehensive credibility score is: Comprehensive score = confidence × (1-risk level × α), where α is a constant between (0, 1) that controls the weight of the impact of the risk level on the score. The value of α can be optimized and adjusted in real time based on historical data or cases.

[0052] Example: The repair strategy library and the corresponding risk level and confidence level are: Strategy 1: Automatic retry, confidence level 0.8. If LSTM predicts a high probability of continuous timeouts, the risk level is 1, which is low risk, and only the operation is retried. Strategy 2: Insert status update code, confidence level 0.75. If the rule engine matches the missing status, the risk level is 2, which is medium risk and involves code changes. Strategy 3: Trigger the circuit breaker mechanism, confidence level 0.65, risk level 3, which is high risk.

[0053] Step C4: Rehearse the repair strategy in a sandbox environment to ensure its feasibility and safety, including: WebAssembly (Wasm) simulation: Use Wasm in the browser to simulate the repaired code execution path, simulate the network environment and user behavior, check whether the critical path is closed, and record the response time after the repair; AST transformation verification: Use Babel's AST toolchain to parse the original code, insert the fix code, and use ESLint or Babel's syntax validator to ensure that the patch has no syntax errors; Failure rollback mechanism: If sandbox verification fails, the policy priority is rolled back, such as policy 1 → policy 2.

[0054] Step C5: Set policy execution conditions, automatically or semi-automatically perform remediation based on the policy risk level, and support cross-service collaboration. In the microservice architecture, notify other services through APIs.

[0055] Example: Execution conditions include: Automatic execution conditions: When confidence > 0.8 and risk level ≤ 2, execute directly. For example, Strategy 1: retry API request, such as fetch() retry 3 times; Strategy 2: dynamically insert code, such as setState('paid'); Manual confirmation execution: When the confidence level is <0.8 or the risk level is >2, a patch suggestion is generated, the code location is highlighted through the VS Code plug-in, and the repair suggestion is displayed for the developer to review and confirm.

[0056] Step C6: Evaluate the repair effect, including path comparison, confirm whether the causal chain breakpoints are repaired, and record the performance indicators after the repair, collect user feedback, optimize the model and root cause library to form a continuous improvement closed loop, and support rollback and audit.

[0057] Among them, model optimization includes: Online learning: Collect repair cases and only update the last layer of the model, such as the Dense layer, to avoid retraining; Transfer learning: Extract repair cases from GitHub Issues, such as "state machine design defect" → "CircuitBreaker mode", and improve generalization ability through data augmentation.

[0058] Among them, root cause library optimization includes: New root cause classification: For example, classify "missing circuit breaker configuration" as "architectural design flaw" and associate it with the design pattern; Rule base update: Add newly discovered root causes to the rule engine, such as "API return format changes" → "Switch to alternate interface".

[0059] On the other hand, the present application also provides a fault-tolerant mechanism for causal chain failure, which ensures system stability and user experience while minimizing data loss and business interruption when anomalies or breaks occur in the causal chain, such as business processes, system status, or data dependencies. Specifically, it includes: Causal chain snapshot storage: prevents data loss caused by memory leaks or program crashes, provides a reliable basis for rollback, uses IndexedDB (front-end) or distributed database (back-end) to persistently store causal chain snapshots, records states by timestamp and version number, supports rollback to any historical valid state, and forces snapshots to be generated at key nodes such as state changes and after asynchronous operations are completed. Secondly, by monitoring indicators such as memory usage and API response time, possible failures can be predicted and snapshots can be triggered in advance. Failure detection and rollback: When a logic break, parameter out-of-bounds or timeout is detected, the system selects the most recent valid snapshot to restore the system state and records the rollback reason and state difference for subsequent analysis.

[0060] Degradation protocol: Set up a tiered strategy to maintain the availability of core functions during failures and avoid a breakdown in user experience.

[0061] The tiered strategies include: First layer: non-critical asynchronous timeout, UI displays "loading" or basic information, and retains core operations; Second layer: The core API fails throughout the entire process, the UI displays cached data, such as historical records, and non-core modules are closed; Third level: Key states are missing, the UI displays static content, and only basic queries are allowed.

[0062] On the other hand, this application also proposes a front-end state anomaly detection system based on causal chain, please refer to the attached Figure 5 The system includes the following modules: Static analysis and modeling module: By parsing the code, it extracts key nodes such as event monitoring, asynchronous tasks, and state changes, and constructs a causal relationship diagram between nodes to form an expected causal chain model as a benchmark for subsequent dynamic verification; Dynamic monitoring and verification module: records the actual path of event triggering, asynchronous calls, and state changes in real time through code hijacking at runtime, and detects anomalies by comparing with the expected causal chain model; Repair module: Combines the rule engine and AI model to locate the root cause of the causal chain anomaly, generates a repair plan based on the policy library, and finally outputs executable repair suggestions; Fault tolerance and rollback module: When an irreversible anomaly is detected, the system is restored to the most recent stable state through the snapshot rollback mechanism, or the function is downgraded according to the preset strategy. It supports selecting the rollback point by time, version or user behavior dimension, and records the difference log; Data storage module: persistently stores causal chain model versions, structured logs of abnormal events, repair strategy execution records, and system status snapshots, supports fast query and analysis, and is integrated into existing monitoring systems; Alarm and notification module: triggers notifications through grading strategies based on the severity and impact of the anomaly, supports custom alarm rules, and generates periodic reports for team review; Verification and execution module: simulates the execution effect of the repair strategy in an isolated environment to ensure that the repair will not introduce new problems, and records the verification results to optimize subsequent strategy selection.

[0063] On the other hand, please see the attached Figure 6 , is a structural diagram of an electronic device provided in an embodiment of this specification, and 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 also include a standard wired interface and a wireless interface, wherein 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 the various parts of the entire electronic device, and executes various functions of the routing device and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory, and calling data stored in the memory. Among them, the processor can be implemented in at least one hardware form of DSP, FPGA, and PLA. The processor can integrate one or a combination of CPU, GPU, modem, etc. Among them, the CPU mainly handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content that needs to be displayed on the display; in this application, the processor can efficiently handle high-computing tasks such as static analysis (AST parsing, DAG construction), dynamic monitoring (hijacking functions, real-time recording), and AI-assisted repair (LSTM reasoning, CML model); the modem is used to handle wireless communications.

[0064] It is understandable that the above-mentioned modem may not be integrated into the processor, but may be implemented 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 may 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, wherein 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 data involved in the above-mentioned various method embodiments, etc. The memory may also be at least one storage device located away from the above-mentioned processor. The memory as a computer storage medium may include an operating system, a network communication module, a user interface module and an application. The processor may be used to call the application 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 record (chain hash structure) and repair strategy library, and support the persistence (IndexedDB) and rollback mechanism of causal chain snapshots.

[0065] The embodiments of this specification also provide a computer-readable storage medium, which stores instructions, and when the instructions are executed on a computer or a processor, the computer or the processor executes the multiple steps in the above embodiments. If the components of the above electronic device are implemented in the form of software functional units and sold or used as independent products, they can be stored in the computer-readable storage medium.

[0066] The embodiments of this specification also provide a computer program product, including a computer program, which implements multiple steps in the above embodiments when executed by a processor.

[0067] In the absence of conflict, the technical features in this embodiment and implementation scheme can be combined arbitrarily.

[0068] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes a plurality of computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of this specification is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from a website site, a computer, a server or a data center to another website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or a data center that includes multiple available media integrated. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state drive (SSD)).

[0069] When implemented by hardware or firmware, the aforementioned method flow is programmed into the hardware circuit to obtain the corresponding hardware circuit structure and realize the corresponding function. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit, and its logic function is determined by the user programming the device. The designer programs by himself to "integrate" a digital system on a PLD, without asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when writing program development, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL), and HDL is not just one, but many. Those skilled in the art should also be aware that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit to easily obtain the hardware circuit that implements the logic method flow.

Claims

1. A front-end state anomaly detection method based on a causal chain, characterized in that: The following steps are involved: Step S1: In the static analysis phase, the calling relationship between event listeners, asynchronous tasks and state change logic is identified by parsing the source code, and an expected causal chain model is constructed; Step S2: During the application running, hijack the key functions, and dynamically verify and compare the actual causal chain with the expected causal chain model; Wherein, in step S1, the source code is parsed by, including but not limited to, AST technology; Among them, in step S2, the hijacking methods of key functions include but are not limited to Proxy mechanism, function packaging and Hook technology.

2. The front-end state anomaly detection method based on causal chain according to claim 1 is characterized in that: In step S1, the steps of 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 cause-effect relationship diagram and divide the levels according to the TRIZ method; Step A3: Rule set verification and model optimization, optimizing the integrity of the causal chain model through static rules and dynamic models; Step A4: Generate an optimized causal chain model.

3. The front-end state anomaly detection method based on causal chain according to claim 2 is characterized in that: In step S2, the verification step of the causal chain includes: Step B1: Hijack key functions through code injection; Step B2: Record the actual execution path, including context information and key data, set up the data structure and build 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.

4. The front-end state anomaly detection method based on causal chain according to claim 3 is characterized in that: In step B3, the verification mechanism includes graph structure comparison and anomaly detection; Among them, graph structure comparison includes: node matching, edge matching, conditional constraints, and sequence verification; Among them, anomaly detection specifically includes: explicit anomalies and implicit anomalies.

5. The front-end state anomaly detection method based on causal chain according to claim 4 is characterized in that: The front-end state anomaly detection method based on the causal chain also includes: After the causal chain anomaly is detected in step S2, repair is performed with the assistance of AI; The steps of the AI-assisted repair include: Step C1: After detecting an anomaly in the causal chain, trigger the repair process to build context features containing multi-dimensional data to provide comprehensive input for AI model reasoning; Step C2: Combine the rule engine with the lightweight model to locate the root cause of the fracture and map it to the TRIZ defect classification to generate a repair template, which provides a basis for repair strategy generation; 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: Rehearse the repair strategy in the sandbox environment to verify its feasibility and safety; Step C5: Set policy execution conditions, perform remediation according to the policy risk level, and support cross-service collaboration. In the microservice architecture, notify other services through APIs; Step C6: Evaluate the repair effect, collect user feedback, optimize the AI ​​model and root cause library to form a continuous improvement closed loop, and support rollback and audit.

6. The front-end state anomaly detection method based on causal chain according to claim 5 is characterized in that: The front-end state anomaly detection method based on causal chain also includes a fault tolerance mechanism for causal chain failure; The fault tolerance mechanism includes: Causal chain snapshot storage: prevents data loss caused by memory leaks and program crashes, provides a reliable basis for rollback, persistently stores causal chain snapshots, records states by timestamp and version number, and supports rollback to any historical valid state; Failure detection and rollback: When a logic break, parameter out-of-bounds, or timeout is detected, the system status is restored using the most recent valid snapshot, and the rollback reason and status difference are recorded for subsequent analysis. Degradation protocol: Set up a tiered strategy to maintain the availability of core functions during failures and avoid a breakdown in user experience.

7. The front-end state anomaly detection system based on causal chain is characterized by: include: Static analysis and modeling module: By parsing the code, it extracts key nodes of event monitoring, asynchronous tasks, and state changes, and constructs a causal relationship diagram between nodes to form an expected causal chain model as a benchmark for subsequent dynamic verification; Dynamic monitoring and verification module: records the actual path of event triggering, asynchronous calls, and state changes in real time through code hijacking at runtime, and detects anomalies by comparing with the expected causal chain model; Repair module: Combines the rule engine and AI model to locate the cause of causal chain anomalies, generates repair plans based on the policy library, and finally outputs executable repair suggestions; Fault tolerance and rollback module: When an irreversible anomaly is detected, the system is restored to the most recent stable state through a snapshot rollback mechanism. It supports selecting a rollback point by time, version, or user behavior, and records a difference log. Data storage module: persistently stores causal chain model versions, structured logs of abnormal events, repair strategy execution records, and system status snapshots, supports fast query and analysis, and is integrated into existing monitoring systems; Alarm and notification module: triggers notifications through grading strategies based on the severity and impact of the anomaly, supports custom alarm rules, and generates periodic reports for team review; Verification and execution module: simulates the execution effect of the repair strategy in an isolated environment to ensure that the repair will not introduce new problems, and records the verification results to optimize subsequent strategy selection.

8. 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 a 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 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. Computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images