Intelligent front-end error repairing method and system based on large model

Abstract

The invention relates to the technical field of front-end application error repair, and provides an intelligent front-end error repair method based on a large model, which comprises the following steps of: calling a JavaScript global error monitor to capture context information during abnormal operation and performing structured packaging; converting a structure field in the context data packet into a corresponding error description text, inputting the corresponding error description text and an error pattern label generated based on historical error case clustering into a large language model for fine tuning of a front-end error repair task, and generating a JavaScript repair patch matched with the running exception; and verifying the repair patch in the sandbox environment, and deploying the repair patch in a hot update mode after the repair patch passes the verification. According to the invention, the integrity of key data required by fault positioning is ensured, and the security of user data is also ensured; in the patch generation stage, clustering analysis is conducted on historical error cases, error pattern labels are generated, the labels serve as prompt prefixes to be injected in the large language model fine adjustment process, and the repair accuracy under a specific error scene is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of front-end application error repair technology, and in particular to a front-end error intelligent repair method and system based on a large model. Background Technology

[0002] As web front-end applications continue to evolve, JavaScript plays an increasingly important role in page interaction, logic control, and data processing. However, because JavaScript is a dynamic language, it lacks compile-time type constraints and error reporting mechanisms, leading to frequent runtime errors. Common error types include TypeError and ReferenceError, such as attempting to call a non-function object, accessing an undefined variable, or reading a property of an empty object. These errors can easily cause partial page functionality to fail, interaction to be interrupted, or even the entire application to crash.

[0003] Current methods for fixing front-end errors primarily rely on manual investigation and static rule monitoring tools. Common approaches include collecting stack traces and basic variables through global error listeners and logging errors using monitoring platforms to assist developers in analysis and handling. However, this approach has the following limitations: ① Traditional tools mostly cannot synchronously record the DOM structure state, user operation path, and network request status at the time of the error, making error reproduction difficult. ② Developers typically need to debug source code line by line in their local environment. Locating errors in compressed or obfuscated online code is difficult, the repair cycle is long, and it requires development environment permissions, failing to meet the real-time repair needs of production environments. ③ Existing automated repair solutions often bypass the verification process, easily introducing secondary errors or performance degradation, and lack a circuit breaker mechanism to handle repair failure scenarios.

[0004] Based on the aforementioned issues, existing technologies still have significant room for improvement in terms of the completeness of error information restoration, the timeliness of the repair process, and the security of automated solutions. Especially with the widespread use of modern complex front-end frameworks and component-based architectures, when a page encounters errors, such as unresponsive key buttons or failed data form loading, traditional repair processes often require disabling functional modules and waiting for a new version release, resulting in user churn and business losses. Therefore, there is an urgent need for an intelligent error handling technology with high-fidelity context capture capabilities, capable of automatically completing diagnosis and repair, and implementing security verification and control, to support efficient fault location and stable operation of front-end applications in production environments. Summary of the Invention

[0005] To address the aforementioned problems, the present invention aims to provide a front-end error intelligent repair method and system based on a large model. This addresses issues in existing technologies such as incomplete error information context acquisition, low repair response efficiency, and lack of verification and rollback mechanisms for automated repair. The invention achieves high-precision capture, intelligent diagnosis, and controllable repair of front-end runtime anomalies, thereby improving the stability and error recovery capabilities of the front-end system in a production environment. The above-mentioned objective of the present invention is achieved through the following technical solutions: This invention provides a front-end error intelligent repair method based on a large model, comprising: Step S1: During the operation of the front-end application, the JavaScript global error listener is invoked to capture runtime exceptions in real time. When a runtime exception is captured, relevant context information is collected and structured and encapsulated to generate a formatted error context data packet. The context information includes the error stack, variable status, page structure, user interaction records, and network request status. Step S2: Based on the pre-built natural language builder, the structure fields in the context data packet are converted into corresponding error description text. The error description text and the error pattern labels generated based on historical error case clustering are used as input and fed into the large language model for fine-tuning the front-end error repair task to generate a JavaScript repair patch that is adapted to the running exception. Step S3: Verify the JavaScript fix in a sandbox environment. After successful verification, deploy it via hot update and implement circuit breaker and rollback control based on a canary release strategy and error rate monitoring mechanism to ensure the safe deployment and stable operation of the JavaScript fix in the production environment.

[0006] Further, step S1 includes: Step S11: Register and call the JavaScript global error listener. The JavaScript global error listener is a runtime exception handling mechanism implemented through the window.onerror or window.addEventListener interface. Step S12: After the JavaScript global error listener is triggered, perform context information collection for runtime exceptions, including: Extract the error stack information, which includes the error type, file path where the error occurred, line number, column number, and call chain information; Retrieves the key variable state from the current function scope, retaining only the values ​​of basic types and their first-level properties, and applies regular expressions to perform desensitization and replacement on fields containing sensitive information. Get the page structure related to the error in the current page. The page structure includes the HTML structure of the trigger node and key style attributes including display, width and height. The system traces back user interaction records before the error was triggered. The user interaction records are limited to information on a preset number of user interaction events. Each user interaction event includes the event type, target element identifier, and the time sequence of the event. Collect the status of incomplete network requests when operational anomalies occur. The network request status includes the request URL, method type, and HTTP status code. Step S13: Encapsulate the collected context information according to a preset data structure to generate the corresponding context data packet.

[0007] Further, in step S2, the structure fields in the context data packet are converted into corresponding error description text based on a preset natural language builder, including: based on a preset construction template, the structure fields extracted from the context data packet are concatenated into natural language error description text according to a fixed format.

[0008] Further, in step S2, the error description text and the error pattern labels generated based on historical error case clustering are used as input to the large language model for fine-tuning the front-end error repair task, generating a JavaScript fix patch adapted to the runtime anomaly, including: The context data packet associated with the error description text is parsed, and the corresponding structure fields are extracted and transformed into a structured error feature vector. The error feature vector is matched with the pre-generated set of historical error pattern labels to obtain the corresponding target error pattern label. The acquired target error pattern labels are injected into the error description text as prefixes to construct error repair prompt statements for input into a large language model; Input the error repair prompts into a large, finely tuned language model based on the Transformer architecture to generate the corresponding JavaScript fix patch.

[0009] Furthermore, step S2 also includes: During the fine-tuning stage of the large language model, historical error cases are preprocessed to generate structured error feature vectors; the error feature vectors are clustered using the DBSCAN density clustering algorithm, and based on the clustering results, at least one error pattern cluster is generated, and the corresponding historical error pattern labels are labeled.

[0010] Furthermore, in step S3, the JavaScript fix patch is verified in a sandbox environment, including: Step S31: Build a sandbox environment for the production environment, load the target application version, and reproduce the page structure and user interaction records described by the context data package; Step S32: After the JavaScript patch is located to the original source code through source mapping, in step S3, function refactoring technology is used to inject it into the sandbox environment, and automated test cases are executed to verify the repair effect of the JavaScript patch.

[0011] Furthermore, after successful verification, deployment is carried out via hot update, and circuit breaker and rollback control are implemented based on the canary release strategy and error rate monitoring mechanism, including: Step S33: After verification, call the hot update interface of the JavaScript engine to replace the bytecode of the running function and complete the hot update deployment of the JavaScript fix patch; Step S34: Deploy the JavaScript patch to running front-end application instances in stages using a canary release strategy, with an initial deployment rate of 5% and gradually expanding to 100%. Step S35: Monitor the error rate changes at each stage after deployment in real time. If the number of errors per minute increases by more than the preset threshold compared to the baseline or a key function test fails, trigger the circuit breaker mechanism and perform a rollback operation. Step S36: The rollback operation includes reverting to the previous stable version in the patch stack. If consecutive rollbacks fail, the page is forcibly refreshed to restore the initial resource state.

[0012] Based on the same inventive concept, this invention provides a front-end error intelligent repair system based on a large model, employing the front-end error intelligent repair method described above, including: The exception collection module is used to call the JavaScript global error listener to capture runtime exceptions in real time during the operation of the front-end application. When a runtime exception is captured, the module collects relevant context information, encapsulates it in a structured manner, and generates a formatted error context data packet. The context information includes error stack, variable status, page structure, user interaction records, and network request status. The patch generation module is used to convert the structural fields in the context data packet into corresponding error description text based on the pre-built natural language builder. The error description text and the error pattern labels generated based on the clustering of historical error cases are used as input to the large language model for fine-tuning the front-end error repair task, and generate JavaScript repair patches that are adapted to the runtime exception. The fix deployment module is used to verify JavaScript fixes in a sandbox environment. Once verified, the fixes are deployed via hot update and circuit breaking and rollback controls are executed based on a canary release strategy and error rate monitoring mechanism to ensure the safe deployment and stable operation of JavaScript fixes in the production environment.

[0013] Furthermore, the anomaly detection module includes: The exception listening unit is used to register and call the JavaScript global error listener, which is a runtime exception handling mechanism implemented through the window.onerror or window.addEventListener interface; The information collection unit is used to collect context information of runtime exceptions after the JavaScript global error listener is triggered. This includes: extracting error stack information, which includes the error type, file path where the error occurred, line number, column number, and call chain information; obtaining the key variable states from the current function scope, retaining only the values ​​of basic types and their first-level properties, and applying regular expressions to perform desensitization and replacement for sensitive fields; obtaining the page structure related to the error in the current page, including the HTML structure of the triggering node and key style attributes including display, width, and height; tracing back and recording user interaction records before the error was triggered, with user interaction records limited to a preset number of user interaction events, each including the event type, target element identifier, and the time sequence of the event; and collecting the status of incomplete network requests when the operational exception occurred, including the request URL, method type, and HTTP status code. The data encapsulation unit is used to encapsulate the collected context information according to a preset data structure and generate the corresponding context data packet.

[0014] Furthermore, the patch generation module includes: The feature vector generation unit is used to parse the context data packet associated with the error description text, extract the corresponding structural fields, and transform them into a structured error feature vector. In the large language model fine-tuning stage, the pattern matching unit preprocesses historical error cases to generate structured error feature vectors; it performs cluster analysis on the error feature vectors using the DBSCAN density clustering algorithm, and classifies them based on the clustering results to generate at least one error pattern cluster, labels the corresponding historical error pattern, and performs similarity matching between the error feature vectors and the pre-generated set of historical error pattern labels to obtain the corresponding target error pattern label. The patch generation unit is used to inject the acquired target error pattern tags as prefixes into the error description text, construct error repair prompt statements for input into the large language model, and input the error repair prompt statements into the large language model based on the Transformer architecture and fine-tuned to generate the corresponding JavaScript repair patch.

[0015] Compared with the prior art, the present invention has at least one of the following beneficial effects: This invention introduces static scoping analysis and regular expression desensitization mechanisms to implement deep restrictions (no more than two levels of attributes) and sensitive information processing on variable states in the context of abnormal operation. This ensures both the integrity of key data required for fault location and the security of user data. During the patch generation phase, error pattern labels are generated by clustering historical error cases. These labels are then injected as prompt prefixes during the fine-tuning of the large language model, effectively improving the model's repair accuracy and robustness in specific error scenarios. For the patch deployment process, this system adopts a sandbox verification mechanism that highly replicates the production environment, combined with bytecode-level function hot-swapping technology, to achieve instant repair deployment without restarting, significantly shortening fault repair time. Furthermore, the system operates in conjunction with canary release and circuit breaker control mechanisms to ensure repair effectiveness while suppressing the propagation of abnormal versions, improving the overall system's self-healing capability and operational stability. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the steps of the intelligent front-end error repair method based on a large model according to the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0019] First Embodiment In current front-end application operation, errors occur frequently, especially in complex interactive scenarios (such as dynamic rendering, asynchronous data requests, and the introduction of third-party components). The diverse error types and complex triggering paths pose significant challenges to problem localization and repair. Existing monitoring tools generally employ passive capture mechanisms based on `window.onerror` or `try-catch`, which can only obtain simple error stack traces and error messages. They lack a comprehensive reconstruction of the context, including the page structure state, user behavior chain, variable snapshots, and network requests at the time of the exception, leading to difficulties in error reproduction and inefficient root cause analysis. Regarding error repair, the current mainstream approach still relies on manual debugging and local development environments. Developers need to locate the minified and obfuscated lines of code, manually reconstruct function call relationships, and write patch code. This is not only inefficient and time-consuming but also carries the risk of misjudging the repair logic due to a lack of contextual understanding, making it difficult to meet the needs for rapid response and real-time repair of online faults. In addition, some solutions that attempt to introduce automated repair capabilities also have flaws. For example, directly generating repair code based on the rule engine or directly replacing function logic in the production environment often does not undergo complete sandbox verification and behavior testing, which may cause new performance problems or logic anomalies. Moreover, once the repair fails, the lack of circuit breaking and rollback mechanisms can easily lead to the expansion of the fault scope.

[0020] To address the shortcomings of existing technologies, such as insufficient error context information, low efficiency due to reliance on manual investigation, and lack of closed-loop protection in repair verification, the inventors propose an automatic front-end error repair scheme based on a large language model. This scheme constructs a multi-dimensional context collection mechanism to systematically record error stacks, variable states, DOM structure, interaction chains, and network request states; introduces error pattern tags generated based on historical case clustering to guide the fine-tuned large language model in generating structured repair patches; and designs a sandbox verification process mirroring the production environment and a hot update deployment mechanism, combined with canary releases and circuit breaker control, to achieve dynamic deployment and secure rollback of repair strategies, thereby constructing a high-precision, low-latency, self-closing front-end exception handling path. The specific implementation is as follows: like Figure 1 As shown, this invention provides a front-end error intelligent repair method based on a large model, used for real-time diagnosis and repair of JavaScript runtime errors in web applications, including: Step S1: During the execution of the front-end application, a global JavaScript error listener is invoked to capture runtime exceptions in real time. When an exception is captured, relevant context information is collected and structurally encapsulated to generate a formatted error context data packet. The context information includes the error stack, variable states, page structure, user interaction records, and network request states. Step S1 includes: Step S11: Register and call the JavaScript global error listener. The JavaScript global error listener is a runtime exception handling mechanism implemented through the window.onerror or window.addEventListener interface. Step S12: After the JavaScript global error listener is triggered, perform context information collection for runtime exceptions, including: Extract the error stack information, which includes the error type, file path where the error occurred, line number, column number, and call chain information; Retrieves the key variable state from the current function scope, retaining only the values ​​of basic types and their first-level properties, and applies regular expressions to perform desensitization and replacement on fields containing sensitive information. Get the page structure related to the error in the current page. The page structure includes the HTML structure of the trigger node and key style attributes including display, width and height. The system traces back user interaction records before the error was triggered. The user interaction records are limited to information on a preset number of user interaction events. Each user interaction event includes the event type, target element identifier, and the time sequence of the event. Collect the status of incomplete network requests when operational anomalies occur. The network request status includes the request URL, method type, and HTTP status code. Step S13: Encapsulate the collected context information according to a preset data structure to generate the corresponding context data packet.

[0021] Specifically, based on JavaScript's global error listening mechanism, such as window.onerror or window.addEventListener('error', ...), it captures common exception types, including TypeError, ReferenceError, and SyntaxError, in real time for front-end runtime exceptions; TypeError, ReferenceError, and SyntaxError are type errors, reference errors, and syntax errors, respectively.

[0022] When an anomaly occurs, the system synchronously collects multi-dimensional context information and constructs a structured error context package (ECP), which includes the following core fields: Error stack information includes the error type, the precise location of the error stack (file path, line number, column number), and complete call chain information; The variable state is scopedVariables, which only serializes basic types and first-level attributes, with a depth of ≤2. Sensitive fields containing keywords such as password / token are de-identified using the regular expression / \b(key|token|auth)=(\w+) / gi, and sensitive values ​​are uniformly replaced with $1=***. The page structure domSnapshot, also known as the component structure snapshot, is the DOM structure snapshot outerHTML of the component that was triggered by the error, along with the calculated values ​​of its core styles. The width, height, and display are extracted using getComputedStyle. Alternatively, it can be interpreted as obtaining the outerHTML snapshot of the target DOM node that triggered the exception, and using the window.getComputedStyle() interface to extract the calculated values ​​of its core style properties (width, height, display), preserving its spatial representation information in the current rendering state. User interaction records, such as interactionTrace, trigger the three most recent user interaction events on the chain, including element ID, event type, and incomplete network request metadata URL, method, and status code. For example, it can trace back the three most recent user interaction events such as click, input, and touch. Each event record contains a unique identifier of the target element, such as ID or class name and event type, which is used to reconstruct the user behavior sequence. The network request status (networkStatus) captures metadata about network requests that are still in progress before an exception occurs. It records the request URL, HTTP method (GET / POST, etc.), and current return status code to help analyze whether the exception was caused by a failed request.

[0023] Finally, it is encapsulated into a layered error context packet (ECP), which contains the core fields errorStack, scopedVariables, domSnapshot, interactionTrace, and networkStatus.

[0024] Step S2: Based on a pre-built natural language builder, the structure fields in the context data packet are converted into corresponding error description text. This error description text, along with error pattern labels generated from historical error case clustering, are input into a large language model used for fine-tuning the front-end error repair task, generating a JavaScript patch adapted to the runtime anomaly. (1) Based on a pre-built natural language builder, the structure fields in the context data packet are converted into corresponding error description text, including: Based on a preset construction template, the structural fields extracted from the context data packet are concatenated into error description text in natural language according to a fixed format.

[0025] Specifically, based on a pre-built natural language builder, or template engine, the Error Context Packet (ECP) is parsed, and its structural fields, including error stack, variable status, page structure, user interaction records, and network request status, are converted into corresponding natural language description text. The description text is used to characterize the triggering context and scope of impact of the current anomaly.

[0026] For example, {errorType: 'TypeError', location: 'Button.js:12', variable:'props.items', userAction: '#submit-btn.click'} can be transformed into "TypeError occurred on line 12 of Button.js: props.items is undefined, triggered when the user clicks #submit-btn".

[0027] (2) The error description text and the error pattern labels generated based on historical error case clustering are used as input to the large language model for fine-tuning the front-end error repair task, generating a JavaScript repair patch adapted to the runtime anomaly, including: The context data packet associated with the error description text is parsed, and the corresponding structure fields are extracted and transformed into a structured error feature vector. The error feature vector is matched with the pre-generated set of historical error pattern labels to obtain the corresponding target error pattern label. The acquired target error pattern labels are injected into the error description text as prefixes to construct error repair prompt statements for input into a large language model; Input the error repair prompts into a large, finely tuned language model based on the Transformer architecture to generate the corresponding JavaScript fix patch.

[0028] It should be specifically noted that during the fine-tuning stage of the large language model, historical error cases are preprocessed to generate structured error feature vectors; the error feature vectors are clustered using the DBSCAN density clustering algorithm, and based on the clustering results, at least one error pattern cluster is generated, and the corresponding historical error pattern labels are labeled.

[0029] Specifically, during the fine-tuning stage of the large language model, density clustering analysis is performed on the feature vectors constructed from historical error cases, and the DBSCAN algorithm is used to automatically discover error clusters with similar structures. Based on the error type, context, and variable features, a unique error pattern label is generated for each cluster, such as "NullReadError-FormSubmit" or "TypeError-AsyncHandler".

[0030] In the current error description text, the most similar error pattern label is matched and injected as a prefix (e.g., "[Pattern#102]"). A complete error repair suggestion statement is constructed and used as input to the large language model. This suggestion statement is then fed into a large language model based on the Transformer architecture and fine-tuned for front-end error repair tasks, outputting JavaScript patch code adapted to the exception. For example, when the error is "props.items undefined", the model can output the following patch logic: if (props.items) { ...} else { ...}.

[0031] During patch generation, the system employs a large language model based on the Transformer architecture (such as T5, CodeGen, or GPT-like models) as the core of patch generation. This model possesses strong context modeling and code generation capabilities. During the pre-training phase, the model has learned a large amount of JavaScript language syntax, common error types, and fix patterns, enabling it to transform natural language problems into code snippets.

[0032] In this embodiment, the model automatically generates patches to fix front-end errors through the following mechanism: ECP structured error data (including stack information, variable states, DOM structure, interaction chains, etc.) is transformed into natural language descriptions through a template engine, and combined with error pattern labels obtained by DBSCAN clustering as prompt prefixes to enhance the model's ability to discriminate the current error semantics. A training set is constructed based on historical error cases, with samples in the form of "error description (including Pattern label) → repair patch," enabling the model to learn the mapping of repair strategies for different error patterns. By adding error pattern labels (such as [Pattern#NullAccess]), the model is guided to establish semantic associations between error patterns and repair strategies, improving the relevance and accuracy of the generated results.

[0033] Upon receiving the enhanced input, the model analyzes the error type, contextual features, and potential triggering conditions in the input based on its multi-layer self-attention mechanism, thereby inferring reasonable protection logic or default value processing structures. Finally, it generates a repair patch with complete syntactic structure and pluggable semantics, for example: if (props.items && Array.isArray(props.items)) { renderList(props.items); } else { console.warn("items is empty, skip rendering"); } This patch not only fixes bugs but also preserves the original functional paths, making it practically deployable.

[0034] Step S3: Verify the JavaScript fix patch in a sandbox environment. After successful verification, deploy it via hot update and implement circuit breaker and rollback control based on a canary release strategy and error rate monitoring mechanism to ensure the secure deployment and stable operation of the JavaScript fix patch in the production environment. Step S3 includes: Step S31: Build a sandbox environment for the production environment, load the target application version, and reproduce the page structure and user interaction records described by the context data package; Step S32: After the JavaScript patch is located to the original source code through source mapping, in step S3, function refactoring technology is used to inject it into the sandbox environment, and automated test cases are executed to verify the repair effect of the JavaScript patch.

[0035] Step S33: After verification, call the hot update interface of the JavaScript engine to replace the bytecode of the running function and complete the hot update deployment of the JavaScript fix patch; Step S34: Deploy the JavaScript patch to running front-end application instances in stages using a canary release strategy, with an initial deployment rate of 5% and gradually expanding to 100%. Step S35: Monitor the error rate changes at each stage after deployment in real time. If the number of errors per minute increases by more than the preset threshold compared to the baseline or a key function test fails, trigger the circuit breaker mechanism and perform a rollback operation. Step S36: The rollback operation includes reverting to the previous stable version in the patch stack. If consecutive rollbacks fail, the page is forcibly refreshed to restore the initial resource state.

[0036] Specifically, a front-end sandbox testing container is built that is highly consistent with the production environment. The sandbox environment is implemented based on the Chromium Embedded Framework (CEF), and the running kernel is specified to be consistent with the current main version of the online browser (such as Chrome v116). The core dependency library versions (such as React 18.2.0) and corresponding Web API support capabilities are loaded synchronously.

[0037] The HTML structure of the error-triggered component is reconstructed based on the domSnapshot field in the context packet (ECP), and simulated user interaction events (including event type, target element, and time interval) are injected to reproduce the error path. The row and column position information in the patch is mapped back to the uncompressed source code function through the SourceMap mechanism, the original function body is obtained using Function.prototype.toString(), and the patch code is embedded into the original function logic to generate a version to be verified.

[0038] Run automated testing processes in the sandbox and implement the following verification strategies: Anomaly detection confirms that the original error has been eliminated and no similar anomalies are thrown again. Check the console output to confirm that there are no new console errors or warnings. Functional correctness testing showed that all preset critical path interaction behaviors were completed as expected. Performance stability verification: Key performance indicators such as function execution time and memory usage fluctuate by no more than 15% compared to the baseline.

[0039] If the sandbox test passes, the native JavaScript engine interfaces (such as %CompileFunction or V8-related APIs) are invoked to hot-swap the bytecode of functions running in the production environment, ensuring that the patch logic can be deployed without interrupting business operations. Deployment adopts a canary release strategy, gradually pushing patches in stages: 5% → 20% → 100%. The following metrics are continuously monitored during deployment: The number of new errors per unit time (e.g., the number of new exceptions per minute). Does the critical path have any function rollback or business anomalies?

[0040] If monitoring results show that the error rate has increased by more than 50% compared to before the patch deployment, or if the core function test fails, the circuit breaker mechanism will be triggered immediately to roll back to the previous stable version in the patch stack; if the rollback fails continuously, location.reload() will be forcibly triggered to clear the dynamically injected logic and restore to the basic resource version.

[0041] Second Embodiment Based on the same inventive concept, this invention provides a front-end error intelligent repair system based on a large model, employing the front-end error intelligent repair method described above, including: The exception collection module is used to call the JavaScript global error listener to capture runtime exceptions in real time during the operation of the front-end application. When a runtime exception is captured, the module collects relevant context information, encapsulates it in a structured manner, and generates a formatted error context data packet. The context information includes error stack, variable status, page structure, user interaction records, and network request status. The patch generation module is used to convert the structural fields in the context data packet into corresponding error description text based on the pre-built natural language builder. The error description text and the error pattern labels generated based on the clustering of historical error cases are used as input to the large language model for fine-tuning the front-end error repair task, and generate JavaScript repair patches that are adapted to the runtime exception. The fix deployment module is used to verify JavaScript fixes in a sandbox environment. Once verified, the fixes are deployed via hot update and circuit breaking and rollback controls are executed based on a canary release strategy and error rate monitoring mechanism to ensure the safe deployment and stable operation of JavaScript fixes in the production environment.

[0042] Furthermore, the anomaly detection module includes: The exception listening unit is used to register and call the JavaScript global error listener, which is a runtime exception handling mechanism implemented through the window.onerror or window.addEventListener interface; The information collection unit is used to collect context information of runtime exceptions after the JavaScript global error listener is triggered. This includes: extracting error stack information, which includes the error type, file path where the error occurred, line number, column number, and call chain information; obtaining the key variable states from the current function scope, retaining only the values ​​of basic types and their first-level properties, and applying regular expressions to perform desensitization and replacement for sensitive fields; obtaining the page structure related to the error in the current page, including the HTML structure of the triggering node and key style attributes including display, width, and height; tracing back and recording user interaction records before the error was triggered, with user interaction records limited to a preset number of user interaction events, each including the event type, target element identifier, and the time sequence of the event; and collecting the status of incomplete network requests when the operational exception occurred, including the request URL, method type, and HTTP status code. The data encapsulation unit is used to encapsulate the collected context information according to a preset data structure and generate the corresponding context data packet.

[0043] Furthermore, the patch generation module includes: The feature vector generation unit is used to parse the context data packet associated with the error description text, extract the corresponding structural fields, and transform them into a structured error feature vector. In the large language model fine-tuning stage, the pattern matching unit preprocesses historical error cases to generate structured error feature vectors; it performs cluster analysis on the error feature vectors using the DBSCAN density clustering algorithm, and classifies them based on the clustering results to generate at least one error pattern cluster, labels the corresponding historical error pattern, and performs similarity matching between the error feature vectors and the pre-generated set of historical error pattern labels to obtain the corresponding target error pattern label. The patch generation unit is used to inject the acquired target error pattern tags as prefixes into the error description text, construct error repair prompt statements for input into the large language model, and input the error repair prompt statements into the large language model based on the Transformer architecture and fine-tuned to generate the corresponding JavaScript repair patch.

[0044] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0045] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A front-end error intelligent repair method based on a large model, characterized in that, include: Step S1: During the operation of the front-end application, the JavaScript global error listener is called to capture runtime exceptions in real time, and relevant context information is collected and structured encapsulated when the runtime exception is captured to generate a formatted error context data packet; The context information includes error stack, variable status, page structure, user interaction records, and network request status; Step S2: Based on the preset natural language builder, the structure fields in the context data packet are converted into corresponding error description text. The error description text and the error pattern labels generated based on historical error case clustering are used as input and input into the large language model for fine-tuning the front-end error repair task to generate a JavaScript repair patch adapted to the running anomaly. Step S3: Verify the JavaScript fix patch in a sandbox environment. After successful verification, deploy it via hot update and execute circuit breaker and rollback control based on a canary release strategy and error rate monitoring mechanism to ensure the secure deployment and stable operation of the JavaScript fix patch in the production environment.

2. The intelligent front-end error repair method according to claim 1, characterized in that, Step S1 includes: Step S11: Register and call the JavaScript global error listener, which is a runtime exception handling mechanism implemented through the window.onerror or window.addEventListener interface; Step S12: After the JavaScript global error listener is triggered, perform the collection of context information for the runtime exception, including: Extract the error stack information, which includes the error type, file path where the error occurred, line number, column number, and call chain information; The key variable states are obtained from the current function scope. The variable states retain only the values ​​of the basic types and their first-level attributes, and regular expressions are applied to perform desensitization and replacement on fields containing sensitive information. Obtain the page structure related to the error in the current page, the page structure including the HTML structure of the trigger node and key style attributes including display, width and height; The system traces back user interaction records prior to the error being triggered. These user interaction records are limited to information on a preset number of user interaction events, and each user interaction event includes an event type, a target element identifier, and the chronological order of the events. Collect the status of incomplete network requests when the operational anomaly occurs. The network request status includes the request URL, method type, and HTTP status code. Step S13: Encapsulate the collected context information according to a preset data structure to generate the corresponding context data packet.

3. The intelligent front-end error repair method according to claim 1, characterized in that, In step S2, the structure fields in the context data packet are converted into corresponding error description text based on a preset natural language builder, including: based on a preset construction template, the structure fields extracted from the context data packet are concatenated into the error description text in natural language according to a fixed format.

4. The intelligent front-end error repair method according to claim 1, characterized in that, In step S2, the error description text and the error pattern labels generated based on historical error case clustering are used as input and fed into a large language model for fine-tuning the front-end error repair task to generate a JavaScript repair patch adapted to the runtime anomaly, including: The context data packet associated with the error description text is parsed, and the corresponding structure fields are extracted and transformed into a structured error feature vector. The error feature vector is matched with the pre-generated set of historical error pattern labels by similarity to obtain the corresponding target error pattern label; The acquired target error pattern label is injected into the error description text as a prefix to construct an error repair prompt statement for input into the large language model; The error repair prompt is input into the large language model based on the Transformer architecture and fine-tuned to generate the corresponding JavaScript repair patch.

5. The intelligent front-end error repair method according to claim 4, characterized in that, Step S2 further includes: During the large language model fine-tuning stage, the historical error cases are preprocessed to generate structured error feature vectors; the error feature vectors are clustered using the DBSCAN density clustering algorithm, and based on the clustering results, at least one error pattern cluster is generated, and the corresponding historical error pattern label is labeled.

6. The intelligent front-end error repair method according to claim 5, characterized in that, In step S3, the JavaScript fix patch is verified in a sandbox environment, including: Step S31: Build the sandbox environment of the mirror production environment, load the target application version, and reproduce the page structure and user interaction records described by the context data packet; Step S32: After the JavaScript patch is located to the original source code through source mapping, in step S3, function refactoring technology is used to inject it into the sandbox environment, and automated test cases are executed to verify the repair effect of the JavaScript patch.

7. The intelligent front-end error repair method according to claim 6, characterized in that, After successful verification, deployment is performed via hot update, and circuit breaker and rollback controls are implemented based on a canary release strategy and error rate monitoring mechanism, including: Step S33: After verification, the hot update interface of the JavaScript engine is called to replace the bytecode of the running function, thus completing the hot update deployment of the JavaScript patch; Step S34: Deploy the JavaScript patch to running front-end application instances in stages using the canary release strategy, wherein the initial deployment ratio is 5% and gradually increases to 100%; Step S35: Monitor the error rate changes at each stage after deployment in real time. If the number of errors per minute increases by more than the preset threshold compared to the baseline or a key function test fails, trigger the circuit breaker mechanism and perform a rollback operation. Step S36: The rollback operation includes reverting to the previous stable version in the patch stack. If consecutive rollbacks fail, the page is forcibly refreshed to restore the initial resource state.

8. A front-end error intelligent repair system based on a large model, employing the front-end error intelligent repair method as described in any one of claims 1 to 7, characterized in that, include: The exception collection module is used to call the JavaScript global error listener to capture runtime exceptions in real time during the operation of the front-end application, and to collect relevant context information and encapsulate it in a structured way to generate a formatted error context data packet when the runtime exception is captured. The context information includes error stack, variable status, page structure, user interaction records, and network request status; The patch generation module is used to convert the structural fields in the context data packet into corresponding error description text based on a pre-set natural language builder. The error description text and the error pattern labels generated based on historical error case clustering are used as input to the large language model for fine-tuning the front-end error repair task, thereby generating a JavaScript repair patch adapted to the runtime anomaly. The repair deployment module is used to verify the JavaScript fix patch in a sandbox environment. After successful verification, it is deployed via hot update and circuit breaker and rollback control are executed based on the canary release strategy and error rate monitoring mechanism to ensure the safe deployment and stable operation of the JavaScript fix patch in the production environment.

9. The intelligent front-end error repair system according to claim 8, characterized in that, The anomaly detection module includes: An exception listening unit is used to register and call the JavaScript global error listener, which is a runtime exception capture mechanism implemented through the window.onerror or window.addEventListener interface; An information collection unit is used to collect the context information of the runtime exception after the JavaScript global error listener is triggered, including: extracting the error stack information, which includes the error type, file path, line number, column number, and call chain information of the occurrence location; obtaining the key variable states from the current function scope, where only the values ​​of basic types and their first-level attributes are retained, and regular expressions are applied to perform desensitization and replacement for sensitive fields; obtaining the page structure related to the error in the current page, which includes the HTML structure of the trigger node and key style attributes including display, width, and height; tracing back and recording user interaction records before the error was triggered, where the user interaction records are limited to information on a preset number of user interaction events, each of which includes the event type, target element identifier, and the time sequence of the event occurrence; and collecting the status of uncompleted network requests when the operational exception occurred, where the network request status includes the request URL, method type, and HTTP status code. The data encapsulation unit is used to encapsulate the collected context information according to a preset data structure to generate the corresponding context data packet.

10. The intelligent front-end error repair system according to claim 9, characterized in that, The patch generation module includes: The feature vector generation unit is used to parse the context data packet associated with the error description text, extract the corresponding structure fields, and convert them into a structured error feature vector. In the large language model fine-tuning stage, the pattern matching unit preprocesses the historical error cases to generate structured error feature vectors; performs cluster analysis on the error feature vectors using the DBSCAN density clustering algorithm, and classifies them based on the clustering results to generate at least one error pattern cluster, labels the corresponding historical error pattern, and performs similarity matching between the error feature vectors and the pre-generated set of historical error pattern labels to obtain the corresponding target error pattern label. The patch generation unit is used to inject the acquired target error pattern label into the error description text as a prefix, construct an error repair prompt statement for input into the large language model; input the error repair prompt statement into the large language model based on the Transformer architecture and fine-tuned, and generate the corresponding JavaScript repair patch.

Images