Task execution exception-oriented automatic fault-tolerant propulsion method and system and storage medium

Abstract

The invention provides an automatic fault-tolerant propulsion method and system for task execution abnormity and a storage medium, and relates to the technical field of distributed system fault-tolerant control, and the method comprises the steps: task dynamic arrangement: arranging tasks into a serial, parallel or dependent execution mode according to a preset dynamic rule, and realizing task trigger execution through an asynchronous thread pool; performing process monitoring, adding a monitoring annotation to an execution method of each task by using an AOP tangent, and capturing a task execution state in real time; performing abnormal grading processing, and executing a strategy according to a pre-configured three-level processing channel; spreading a dependency state, and automatically updating an associated task state based on a dependency relationship among the tasks: when an upstream task fails, pausing a downstream dependency task and marking the downstream dependency task as a waiting state, and continuing to execute a non-dependency task; and performing global state statistics, calculating a global state in real time through a task state algorithm, if all tasks are completed, marking the tasks as completed, if abnormal tasks exist, marking the tasks as abnormal, and triggering root cause analysis.

Description

Technical Field

[0001] This invention relates to the field of fault-tolerant control technology for distributed systems, and more specifically, to a method for self-healing of task execution anomalies in financial-grade systems. Background Technology

[0002] In financial fund management systems, daily cutoff tasks such as clearing, reconciliation, and interest settlement need to be executed automatically in sequence. However, existing technologies have many shortcomings: high task coupling means that an anomaly in a single task can trigger an overall interruption of the execution chain, requiring manual reset and restarting, severely impacting the timeliness of the daily cutoff window; crude anomaly handling requires manual intervention for all anomalies, and tasks cannot be recovered from breakpoints; and a disconnect between monitoring and analysis, with task logs and anomaly handling operating independently, leading to inefficient root cause analysis relying on manual investigation. Existing solutions cannot meet the automation and high reliability requirements of financial systems. Summary of the Invention

[0003] The purpose of this invention is to provide an automatic fault-tolerant advancement method, system, and storage medium for task execution anomalies, so as to solve the problems of insufficient intelligence and fault tolerance defects in the prior art.

[0004] To address the aforementioned issues, this invention first provides an automatic fault-tolerant advancement method for task execution exceptions, comprising the following steps: dynamic task orchestration, where tasks are orchestrated into serial, parallel, or dependent execution modes according to preset dynamic rules, and task triggering execution is implemented through an asynchronous thread pool; execution process monitoring, where monitoring annotations are added to the execution methods of each task using AOP aspects to capture the task execution status in real time, including success, exception, or failure, where exception types are distinguished from business exceptions and system exceptions through custom annotations; and exception hierarchical handling, where when a task status is exception or failure, an execution strategy is implemented according to a pre-configured three-level processing channel: if it is a non-critical exception... For tasks that fail, an automatic retry mechanism is triggered, retrying the task a preset number of times and at preset intervals. If the task is a critical exception, its status is saved to the database, an exception work order is generated, and the task is transferred to manual processing. If the task is an ignoreable exception, its status is marked as ignored, and execution is skipped. Dependency status propagation is implemented, automatically updating the status of related tasks based on the dependencies between tasks: when an upstream task fails, downstream dependent tasks are paused and marked as waiting, while non-dependent tasks continue to execute. Global status statistics are performed, calculating the global status in real time using a task status algorithm based on task execution results and dependencies. If all tasks are completed, they are marked as completed; if there are exception tasks, they are marked as exceptions, and root cause analysis is triggered.

[0005] Furthermore, the dynamic rules include: parallel execution rules, where tasks without dependencies are executed concurrently through isolated thread pool resources; and dependency execution rules, where dependencies are established through task numbers, and downstream tasks are started only when the upstream task is in a completed or ignored state.

[0006] Furthermore, the hierarchical handling of anomalies is implemented through the following mechanisms: anomaly type identification, which uses AOP aspects to intercept anomalies and distinguishes between business anomalies and system anomalies based on the anomaly codes in the annotations; and a three-level processing channel, which defines the mapping relationship between anomaly types and processing strategies through externalized configuration files, supporting dynamic adjustment at runtime.

[0007] Furthermore, the task status algorithm includes: retrieving all task statuses from the database and grouping them into completed, abnormal, and waiting categories; if the number of abnormal tasks is greater than 0, the global status is set to abnormal; if the number of waiting tasks is greater than 0, the global status is set to waiting; if all tasks are completed, the global status is set to completed.

[0008] This invention also provides an automatic fault-tolerant advancement system for task execution anomalies, comprising: a task orchestration module, used to orchestrate tasks into serial, parallel, or dependent execution modes according to preset dynamic rules, and generate task execution plans; an execution monitoring module, integrating an AOP aspect framework, injecting monitoring logic into the task execution method, capturing task status in real time, including success, anomaly, or failure, and distinguishing between business anomalies and system anomalies based on custom annotations; an anomaly handling module, executing a strategy according to a pre-configured three-level processing channel: triggering an automatic retry mechanism for non-critical anomaly tasks; saving the status of critical anomaly tasks to the database and generating manual work orders; marking negligible anomaly tasks as ignored and skipping their execution; a status propagation module, dynamically updating the status of associated tasks based on the dependencies between tasks, setting downstream tasks to a waiting state and pausing execution when an upstream task fails; and a global statistics module, calculating the global status in real time using a task status algorithm, marking tasks as completed if all tasks are completed, and marking any anomaly tasks as anomalies and triggering root cause analysis.

[0009] Furthermore, the dynamic rules include: parallel execution rules, where tasks without dependencies are executed concurrently through isolated thread pool resources; and dependency execution rules, where dependencies are established through task numbers, and downstream tasks are started only when the upstream task is in a completed or ignored state.

[0010] Furthermore, the exception handling module is implemented through the following mechanisms: exception type identification, using AOP aspects to intercept exceptions, and distinguishing between business exceptions and system exceptions based on the exception codes in the annotations; a three-level processing channel, defining the mapping relationship between exception types and processing strategies through an externalized configuration file, supporting dynamic adjustment at runtime.

[0011] Furthermore, the task status algorithm includes: retrieving all task statuses from the database and grouping them into completed, abnormal, and waiting categories; if the number of abnormal tasks is greater than 0, the global status is set to abnormal; if the number of waiting tasks is greater than 0, the global status is set to waiting; if all tasks are completed, the global status is set to completed.

[0012] The present invention also provides an electronic device, comprising: a processor, and a memory connected to the processor; the memory storing computer execution instructions; the processor executing the computer execution instructions stored in the memory to implement the automatic fault-tolerant advancement method for task execution exceptions as described in any of the above technical solutions.

[0013] The present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when executed, are used to implement the automatic fault-tolerant advancement method for task execution exceptions as described in any of the above technical solutions.

[0014] The automatic fault-tolerant advancement method, system, and storage medium for task execution anomalies provided by the present invention have the following advantages:

[0015] Dynamic and flexible, supporting parallel, serial, and dependent execution modes of tasks, breaking through rigid process limitations and improving resource utilization;

[0016] Intelligent fault tolerance automatically distinguishes the type of exception and executes retry, ignore, or transfer to manual intervention strategies to reduce manual intervention and ensure daily switching efficiency;

[0017] Fault isolation: Dependent task status is automatically propagated while non-dependent tasks are unaffected, preventing the spread of faults;

[0018] Traceability, real-time status calculation and persistent storage, supporting rapid fault location and root cause analysis. Attached Figure Description

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

[0020] Figure 1 The flowchart illustrates the automatic fault-tolerant advancement method for task execution exceptions provided in this embodiment of the invention. Detailed Implementation

[0021] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0022] Example 1

[0023] This embodiment provides an automated fault-tolerant advancement method for handling task execution anomalies, primarily applied to ensure the efficiency of daily task switching in a financial funds management system. Taking the daily task switching process of a bank's funds management system as an example, three core tasks—fund clearing, reconciliation, and interest accrual—must be completed sequentially every morning. In traditional solutions, tasks are executed serially in a fixed order. If an anomaly occurs in the reconciliation process, the entire process is interrupted, requiring manual correction and retrying, leading to the risk of timeout during the daily task switching window. This embodiment uses a dynamic fault-tolerant advancement method to automatically handle anomalies and ensure process continuation.

[0024] like Figure 1 As shown, this propulsion method specifically includes the following steps:

[0025] S1 Task Dynamic Orchestration

[0026] Orchestration rule configuration: Parallel execution. The clearing task Task001 and the reconciliation task Task002 have no dependency relationship. They are executed concurrently through independent thread pools, such as the clearing thread pool and the reconciliation thread pool, reducing overall execution time. Dependency execution: The interest settlement task Task003 depends on the reconciliation results. The dependency rule for Task003 is defined in the configuration file as the upstream task being Task002. Task003 will only start automatically when the status of Task002 is "completed" or "ignored".

[0027] Execution triggering process: When the system starts up on a daily basis, it executes tasks according to the task orchestration rules; it asynchronously submits Task001 and Task002 to the corresponding thread pools and executes them simultaneously; it monitors the status of Task002 in real time, and if it is completed, it triggers Task003 to prepare for execution.

[0028] S2 execution process monitoring

[0029] Aspect-oriented programming (AOP) injection adds an aspect annotation to the `checkAccount` method of the reconciliation task. This annotation implements the following monitoring logic through the AOP framework:

[0030] Pre-monitoring: Record task start time and input parameters (such as reconciliation date and account range);

[0031] Return monitoring: If the method returns normally, record the reconciliation result (success, exception);

[0032] Anomaly monitoring: Intercept thrown exceptions and distinguish between business anomalies and system anomalies through annotations.

[0033] Example of status capture: When a data format error occurs during the execution of Task002, i.e. a business error, the aspect immediately captures and marks the task status as "error", and records the error code as the business error type, such as BIZ-001.

[0034] S3 Abnormal Classification and Handling

[0035] When a task is in an abnormal or failed state, the execution strategy is based on the pre-configured three-level processing channel:

[0036] 1. If it is a non-critical abnormal task, trigger the automatic retry mechanism and retry according to the preset number of times and intervals;

[0037] For example, Task002 fails to execute on its first attempt due to network fluctuations, which is a system exception, coded as SYS-002: the exception type is detected as retryable, triggering a 3-retry mechanism with a 5-second interval; during the second retry, the network recovers, the task executes successfully, and the status is updated to "completed".

[0038] 2. If it is a critical exception task, save the task status to the database, generate an exception work order and transfer it to manual processing;

[0039] For example, Task002 failed due to a database table structure change, which is a business exception, coded BIZ-003: The system automatically saves the current reconciliation progress (e.g., 80% of the account reconciliation has been completed) to the database; generates an exception work order, including the task number, exception details, and breakpoint location, and pushes it to the operations and maintenance personnel; after the operations and maintenance personnel correct the table structure, they click "Resume Execution" in the work order system, and the system continues the reconciliation from the breakpoint.

[0040] 3. If the task is an ignoreable exception, mark its status as ignored and skip its execution;

[0041] For example, if Task002 encounters a historical data redundancy warning, which is an ignorable exception, coded as IGN-001: the system marks the task status as "ignored", skips the verification steps corresponding to the exception, and continues to execute the remaining reconciliation process without affecting the overall progress.

[0042] S4 Dependency State Propagation

[0043] Based on the dependencies between tasks, the status of related tasks is automatically updated: when an upstream task fails, downstream dependent tasks are paused and marked as waiting, while non-dependent tasks continue to execute.

[0044] If the reconciliation task in Task002 is transferred to manual processing due to a critical anomaly, its status will change to "Abnormal":

[0045] If Task003 is detected to depend on Task002, the status of Task003 will be automatically set to "waiting" and execution will be paused. Non-dependent tasks (such as the concurrently running liquidation task Task001) will not be affected and will continue to complete the liquidation.

[0046] S5 Global Status Statistics

[0047] 1. State Algorithm Execution Flow

[0048] Retrieve all task statuses from the database: Task001 (Completed), Task002 (Exception), Task003 (Waiting);

[0049] Statistics by status: Number of abnormal tasks = 1, Number of waiting tasks = 1;

[0050] Due to the existence of an abnormal task, the global status is marked as "abnormal," and a status report is generated:

[0051] Completed tasks: 1 (clearing); Abnormal tasks: 1 (reconciliation, requires manual processing); Pending tasks: 1 (interest settlement, depends on reconciliation results).

[0052] 2. Root cause analysis triggered

[0053] When the global status is "abnormal", the system automatically analyzes the abnormal task log, for example:

[0054] The specific error for the reconciliation anomaly was "table structure missing field balance", which indicated that the database changes were not synchronized to the reconciliation module, triggering an operation and maintenance alarm.

[0055] Example 2

[0056] This embodiment provides an automatic fault-tolerant propulsion system for task execution anomalies, which can implement the propulsion method provided in this embodiment, specifically including:

[0057] The task orchestration module is used to orchestrate tasks into serial, parallel, or dependent execution modes according to preset dynamic rules and generate task execution plans. The dynamic rules include: parallel execution rules, where tasks without dependencies are executed concurrently through isolated thread pool resources; and dependent execution rules, where dependencies are established by task number, and downstream tasks are started only when the upstream task is in the completed or ignored state.

[0058] The execution monitoring module integrates an AOP aspect framework, injects monitoring logic into the task execution method, captures the task status in real time, including success, exception, or failure, and distinguishes between business exceptions and system exceptions based on custom annotations.

[0059] The exception handling module executes the strategy according to the pre-configured three-level processing channel: triggering an automatic retry mechanism for non-critical exception tasks; saving the status of critical exception tasks to the database and generating a manual work order; and marking negligible exception tasks as ignored and skipping their execution.

[0060] The state propagation module dynamically updates the state of associated tasks based on the dependencies between tasks. When an upstream task fails, the downstream task is set to a waiting state and its execution is paused.

[0061] The global statistics module calculates the global status in real time using a task status algorithm. If all tasks are completed, the task is marked as completed; if any tasks are abnormal, they are marked as abnormal, triggering root cause analysis. The task status algorithm includes: retrieving the status of all tasks from the database and grouping them into completed, abnormal, and waiting categories; if the number of abnormal tasks is greater than 0, the global status is set to abnormal; if the number of waiting tasks is greater than 0, the global status is set to waiting; if all tasks are completed, the global status is set to completed.

[0062] The exception handling module is implemented through the following mechanism:

[0063] Exception type identification: Exceptions are intercepted using AOP aspects, and business exceptions and system exceptions are distinguished based on the exception codes in the annotations.

[0064] The three-level processing channel defines the mapping relationship between exception types and processing strategies through an externalized configuration file, and supports dynamic adjustment at runtime.

[0065] Based on the scenario shown in Example 1, the task orchestration module generates a daily task plan, defining Task001 and Task002 as running in parallel, and Task003 as dependent on Task002; the execution monitoring module captures business exceptions in Task002 through AOP aspects and passes them to the exception handling module; the exception handling module determines that it is a critical exception, saves the status and generates a work order; the status propagation module updates Task003 to a waiting state; the global statistics module calculates the global status as abnormal and triggers root cause analysis.

[0066] If the system load is too high during the daily switching process, the orchestration rules can be dynamically adjusted through the external configuration file. For example, the parallel execution of Task001 and Task002 can be changed to serial execution to release thread resources; the exception retry strategy can be adjusted, such as extending the retry interval from 5 seconds to 10 seconds to reduce resource consumption.

[0067] Example 3

[0068] This embodiment provides an electronic device, including: a processor and a memory connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the automatic fault-tolerant advancement method for task execution exceptions as provided in Embodiment 1.

[0069] Example 4

[0070] This embodiment provides a computer-readable storage medium storing computer-executable instructions. When these instructions are executed, they are used to implement the automatic fault-tolerant advancement method for task execution exceptions as provided in Embodiment 1.

[0071] This invention addresses the high timeliness and reliability requirements of daily task switching in financial systems, achieving a systematic breakthrough in terms of task scheduling flexibility, intelligent anomaly handling, fault isolation capabilities, and state management efficiency. The beneficial effects are as follows:

[0072] Dynamic task orchestration improves execution efficiency and resource utilization, breaking through rigid process limitations and supporting dynamic switching between serial, parallel, and dependent execution modes, avoiding resource waste caused by traditional fixed sequences. Asynchronous thread pools enable concurrent task scheduling, utilizing multi-core CPU resources to allow dependent tasks to proceed synchronously, significantly improving resource utilization. Intelligent dependency management automatically establishes dependency chains based on task numbers, with downstream tasks only starting when their status is "completed" or "ignored," avoiding unnecessary waiting. It also features dynamic adjustment of execution modes; when system load is too high, parallel tasks can be converted to serial execution, balancing performance and stability.

[0073] By using AOP aspects and custom annotations to distinguish exception types, a three-level processing channel is implemented, enabling automatic classification and hierarchical handling of exceptions. The automatic handling rate of low-probability exceptions is improved, and the number of scenarios requiring manual intervention is reduced, thereby reducing the cost of manual intervention.

[0074] A fault isolation mechanism prevents the spread of anomalies from causing a global outage. When an upstream task fails, only downstream dependent tasks are paused, while non-dependent tasks continue execution, avoiding the fund settlement delays caused by a complete process interruption in traditional solutions. The granularity of fault isolation is refined from the entire process to the dependent task chain, reducing the scope of anomaly impact. A global state algorithm calculates the task chain state in real time, ensuring that the state of each task is consistent with its dependencies, avoiding the risk of data inconsistency.

[0075] Real-time monitoring and status management accelerate fault location; AOP aspects capture task execution status in real time, and combine this with log records of input parameters, execution time, and exception details to form a complete task execution trajectory, enabling full-process visual monitoring. The global status algorithm automatically marks "abnormal" task chains and triggers root cause analysis, achieving an alarm accuracy rate of over 95%, reducing false alarm interference, and realizing intelligent status statistics and alarms.

[0076] Customized solutions for financial scenarios ensure business continuity; parallel execution and automatic recovery mechanisms ensure that daily task cutoffs are completed within strict time windows, improving the timeliness of core processes such as fund clearing and reconciliation, and fully meeting the rigid requirement of "daily task cutoffs without timeout" in financial systems. State preservation in the event of critical anomalies ensures task recovery, avoiding data loss or duplicate processing due to anomalies, and meeting the atomicity requirements of financial transactions.

[0077] In the description of this embodiment, it should be noted that those skilled in the art will understand that all or part of the processes in the above-described embodiments can be implemented by a computer program instructing a control device. The program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the above-described method embodiments. The storage medium can be a memory, a disk, an optical disk, etc.

[0078] Although the present invention is disclosed as above, the present invention is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention should be based on the scope defined by the claims.

[0079] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0080] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0081] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An automatic fault-tolerant advancement method for task execution exceptions, characterized in that, The following steps are involved: Dynamic task orchestration arranges tasks into serial, parallel, or dependent execution modes according to preset dynamic rules, and implements task triggering and execution through an asynchronous thread pool. Execution process monitoring: AOP aspects are used to add monitoring annotations to the execution methods of each task to capture the task execution status in real time. The execution status includes success, exception, or failure. The exception type is distinguished from business exceptions and system exceptions through custom annotations. Anomaly handling is tiered. When a task is in an abnormal or failed state, a pre-configured three-tiered processing strategy is executed: If it is a non-critical abnormal task, the automatic retry mechanism will be triggered, and the task will be retried according to the preset number of times and intervals. If it is a critical abnormal task, save the task status to the database, generate an abnormal work order and transfer it to manual processing; If the exception is negligible, mark the task status as ignored and skip execution; Dependency state propagation automatically updates the state of associated tasks based on the dependencies between tasks: when an upstream task fails, downstream dependent tasks are paused and marked as waiting, while non-dependent tasks continue to execute. Global status statistics are calculated in real time based on task execution results and dependencies using a task status algorithm. If all tasks are completed, they are marked as completed; if there are any abnormal tasks, they are marked as abnormal and root cause analysis is triggered.

2. The automatic fault-tolerant advancement method for task execution exceptions according to claim 1, characterized in that, The dynamic rules include: Parallel execution rules: Tasks with no dependencies are executed concurrently through isolated thread pool resources; The execution rules are based on task numbers. Downstream tasks are only started when the upstream task is in a completed or ignored state.

3. The automatic fault-tolerant advancement method for task execution anomalies according to claim 2, characterized in that, The anomaly classification and handling is implemented through the following mechanism: Exception type identification: Exceptions are intercepted using AOP aspects, and business exceptions and system exceptions are distinguished based on the exception codes in the annotations. The three-level processing channel defines the mapping relationship between exception types and processing strategies through an externalized configuration file, and supports dynamic adjustment at runtime.

4. The automatic fault-tolerant advancement method for task execution anomalies according to claim 3, characterized in that, The task status algorithm includes: Retrieve all task statuses from the database and group them into completed, error, and pending categories for statistical analysis. If the number of abnormal tasks is greater than 0, the global status is set to abnormal. If the number of waiting tasks is greater than 0, the global state is set to waiting. If all tasks are completed, the global state is set to completed.

5. An automatic fault-tolerant propulsion system for task execution anomalies, characterized in that, include: The task orchestration module is used to orchestrate tasks into serial, parallel, or dependent execution modes according to preset dynamic rules and generate task execution plans. The execution monitoring module integrates an AOP aspect framework, injects monitoring logic into the task execution method, captures the task status in real time, including success, exception, or failure, and distinguishes between business exceptions and system exceptions based on custom annotations. The exception handling module executes the strategy according to the pre-configured three-level processing channel: triggering an automatic retry mechanism for non-critical exception tasks; saving the status of critical exception tasks to the database and generating a manual work order; and marking negligible exception tasks as ignored and skipping their execution. The state propagation module dynamically updates the state of associated tasks based on the dependencies between tasks. When an upstream task fails, the downstream task is set to a waiting state and its execution is paused. The global statistics module calculates the global status in real time using a task status algorithm. If all tasks are completed, the task is marked as completed; if there are any abnormal tasks, they are marked as abnormal and root cause analysis is triggered.

6. The automatic fault-tolerant propulsion system for task execution anomalies according to claim 5, characterized in that, The dynamic rules include: Parallel execution rules: Tasks with no dependencies are executed concurrently through isolated thread pool resources; The execution rules are based on task numbers. Downstream tasks are only started when the upstream task is in a completed or ignored state.

7. The automatic fault-tolerant propulsion system for task execution anomalies according to claim 6, characterized in that, The exception handling module is implemented through the following mechanism: Exception type identification: Exceptions are intercepted using AOP aspects, and business exceptions and system exceptions are distinguished based on the exception codes in the annotations. The three-level processing channel defines the mapping relationship between exception types and processing strategies through an externalized configuration file, and supports dynamic adjustment at runtime.

8. The automatic fault-tolerant propulsion system for task execution anomalies according to claim 7, characterized in that, The task status algorithm includes: Retrieve all task statuses from the database and group them into completed, error, and pending categories for statistical analysis. If the number of abnormal tasks is greater than 0, the global status is set to abnormal. If the number of waiting tasks is greater than 0, the global state is set to waiting. If all tasks are completed, the global state is set to completed.

9. An electronic device, characterized in that, include: A processor, and a memory connected to the processor; The memory stores computer-executed instructions; The processor executes the computer execution instructions stored in the memory to implement the automatic fault-tolerant advancement method for task execution exceptions as described in any one of claims 1-4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed, are used to implement the automatic fault-tolerant advancement method for task execution exceptions as described in any one of claims 1-4.

Images