Task scheduling method, task scheduling device and automatic coding system

Abstract

This disclosure provides a task scheduling method, a task scheduling device, and an automatic coding system, relating to the field of computer technology, and particularly to the field of artificial intelligence technology. The method includes: retrieving a target event from at least one type of event queue using a distributed lock mechanism, wherein the target event is retrieved by one of multiple scheduler instances; determining a subtask of the code development task corresponding to the target event; selecting an executor instance from multiple executor instances, and assigning the subtask corresponding to the target event to the selected executor instance. This scheme improves the efficiency and reliability of the automatic coding system.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to task scheduling methods, task scheduling devices, and automatic coding systems in the field of artificial intelligence technology. Background Technology

[0002] With the rapid development of artificial intelligence technology, using automatic coding systems has become a reality and is gradually becoming a technological trend. However, as more and more developers use automatic coding systems, ensuring their efficiency and reliability has become an urgent problem to be solved. Summary of the Invention

[0003] This disclosure provides a task scheduling method, a task scheduling device, an automatic coding system, an electronic device, a non-transitory computer-readable storage medium, and a computer program product to improve the efficiency and reliability of automatic coding systems.

[0004] According to a first aspect of this disclosure, a task scheduling method is provided, the method comprising: A target event is retrieved from an event queue of at least one type using a distributed lock mechanism, wherein the target event is retrieved by one of multiple scheduler instances; Determine the subtasks of the code development task corresponding to the target event; Select an executor instance from multiple executor instances, and assign the subtask of the code development task corresponding to the target event to the selected executor instance.

[0005] According to a second aspect of this disclosure, an automatic coding system is provided, the system comprising multiple scheduler instances and multiple executor instances; The scheduler instance is configured to retrieve a target event from at least one type of event queue through a distributed lock mechanism; determine a subtask of the code development task corresponding to the target event; select an executor instance from the plurality of executor instances, and assign the subtask of the code development task corresponding to the target event to the selected executor instance; The executor instance is configured to execute subtasks assigned by the scheduler instance.

[0006] According to a third aspect of this disclosure, a task scheduling apparatus is provided, the task scheduling apparatus comprising: An event acquisition unit is configured to acquire a target event from at least one type of event queue via a distributed lock mechanism, wherein the target event is acquired by one of a plurality of scheduler instances; The task determination unit is configured to determine the subtasks of the code development task corresponding to the target event; The task allocation unit is configured to select an executor instance from a plurality of executor instances and allocate the subtasks of the code development task corresponding to the target event to the selected executor instance.

[0007] According to a fourth aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect above.

[0008] According to a fifth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method described in the first aspect above.

[0009] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0010] As can be seen from the above technical solutions, both the scheduler instance and the executor instance in this disclosure adopt a distributed cluster approach. The scheduler instance coordinates its access to the event queue through a distributed lock mechanism, selects an executor instance from multiple executor instances, and assigns the subtasks of the code development task corresponding to the target event to the executor instance. This approach can effectively improve the throughput of the automatic coding system, thereby improving its efficiency. Furthermore, the redundant design of multiple executor instances and multiple scheduler instances effectively improves the reliability of the automatic coding system.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure.

[0013] Figure 1 This is an exemplary system architecture diagram to which embodiments of this disclosure can be applied.

[0014] Figure 2 A schematic flowchart illustrating the task scheduling method provided in the embodiments of this disclosure.

[0015] Figure 3 A schematic block diagram of a task scheduling device provided in an embodiment of this disclosure.

[0016] Figure 4 This is a block diagram of an electronic device used to implement the task scheduling method of the embodiments of this disclosure. Detailed Implementation

[0017] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0018] In the field of code development technology, the common approach is to use a central scheduler to receive user requirements, transform them into specific code development tasks, and then assign them to one or more executors to complete. However, this approach does not perform ideally when applied to large-scale, high-concurrency enterprise-level development scenarios.

[0019] In view of this, this disclosure provides a completely new approach. To facilitate understanding of the embodiments of this disclosure, the system architecture on which this disclosure is based will first be described. Figure 1 Exemplary system architectures that can be applied to embodiments of this disclosure are shown, such as Figure 1 As shown, the system architecture may include: a user-side and an automatic coding system (or code development system / software development system, etc.) set up on the server side.

[0020] The server side and the client side are the two main components of an application service. The server side uses a server as its primary hardware infrastructure and may include one or more software service modules. The server side and the client side form a collaborative front-end and back-end.

[0021] The client can be set on the terminal device. In this embodiment of the disclosure, the client can be a local application, a mini-program, or a web application running through a browser on the terminal device.

[0022] A server can be a single server, a server cluster consisting of multiple servers, or a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product in the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak service scalability.

[0023] In this embodiment, the user client can submit development requirement information input by the user to the automatic coding system on the server side. The automatic coding system automatically generates code based on the development requirement information. In this embodiment, the automatic coding system includes multiple scheduler instances and multiple executor instances. That is, not only do the executor instances adopt a distributed cluster approach, but the scheduler instances also adopt a distributed cluster approach. The scheduler instances are used to schedule tasks using the method provided in this embodiment, and the executor instances are used to execute sub-tasks at each stage of the code development task. During the execution of each sub-task, the executor instances may involve accessing remote storage space, specification databases, code repositories, etc., and may also involve invoking coding agents.

[0024] It should be understood that Figure 1 The number of client terminals, automatic coding systems, remote storage spaces, specification databases, code repositories, and coding agents shown is merely illustrative. Depending on implementation needs, any number of client terminals, automatic coding systems, remote storage spaces, specification databases, code repositories, and coding agents can be included.

[0025] Figure 2 This is a schematic flowchart illustrating a task scheduling method provided in an embodiment of this disclosure. The method can be... Figure 1 The scheduler instance in the system shown executes, such as Figure 2 As shown, the executor instance performs the following steps: Step 201: Obtain the target event from an event queue of at least one type using a distributed lock mechanism. The target event is obtained by one of multiple scheduler instances.

[0026] Step 203: Determine the subtasks of the code development task corresponding to the target event.

[0027] Step 205: Select an executor instance from multiple executor instances and assign the subtasks of the code development task corresponding to the target event to the selected executor instance.

[0028] As can be seen, both the scheduler instance and the executor instance in this disclosure adopt a distributed cluster approach. The scheduler instance coordinates its access to the event queue through a distributed lock mechanism, allocating the subtasks of the code development task corresponding to the target event to the executor instance. This approach can effectively improve the throughput of the automatic coding system, thereby improving its efficiency. Furthermore, the redundant design of multiple executor instances and multiple scheduler instances effectively improves the reliability of the automatic coding system.

[0029] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments. It should be noted that the terms "first" and "second" used in this disclosure do not have limitations on size, order, or quantity, but are only used to distinguish them by name. For example, "first actuator instance" and "second actuator instance" are only used to distinguish two actuator instances by name.

[0030] First, the above step 201, namely "obtaining the target event from at least one type of event queue through a distributed lock mechanism", will be described in detail with reference to the embodiments.

[0031] In this disclosure, the term "instance" refers to a standalone, fully functional process, container, or computing unit. For example, a scheduler instance is a standalone running process, container, or computing unit of a scheduler program, capable of independently acquiring tasks, making scheduling decisions, and allocating tasks; multiple scheduler instances form a scheduler cluster. Similarly, an executor instance is a standalone running process, container, or computing unit of an executor program, capable of independently executing tasks; multiple executor instances form an executor cluster.

[0032] In a distributed scheduler cluster, multiple scheduler instances compete to acquire events in the event queue. The core function of a distributed lock is to ensure that the same event can only be acquired by one of the multiple scheduler instances at the same time, thereby avoiding scheduling conflicts or duplicate scheduling.

[0033] One possible approach is for a scheduler instance to request a queue-level lock on the target queue containing the target event, retrieve the target event from the queue, and then release the queue-level lock. While the queue is locked, no other scheduler instance can access the event queue except for the one that requested the queue-level lock.

[0034] For example, before attempting to retrieve a target event from an event queue, a scheduler instance first requests a lock from a distributed lock service, identified by the queue's name. Only a scheduler instance that successfully acquires the lock can retrieve an event from the queue, and immediately release the lock after the operation is complete. This approach uses the entire queue as the lock granularity, is simple to implement, and can quickly process events in the queue with minimal lock contention overhead.

[0035] As an alternative approach, a scheduler instance can acquire an event-level lock for a target event, retrieve the target event from its target queue, and then release the event-level lock. While the event is locked, no other scheduler instance can access it except for the one that acquired the lock.

[0036] For example, a scheduler instance first determines the identifier of the target event, and then uses that identifier as the key to request a distributed lock. Only a scheduler instance that successfully acquires the lock can retrieve the target event from the event queue, and immediately release the lock after the operation is complete. This approach uses a single event as the lock granularity, resulting in higher precision, and allows multiple scheduler instances to process different events in the same queue simultaneously, further improving system throughput.

[0037] In this disclosure, the term "target event" refers to a single event message retrieved from the event queue and currently awaiting processing. It typically carries information necessary to trigger subsequent processing. The autocoding system can maintain multiple types of event queues to categorize and store different types of events. For example, four event queues might be used to store events such as new code development tasks, user-returned confirmation of execution plan information, user-returned rejection of execution plan information, and code review system-rejected review results. The meanings of these events and the triggered subsequent processing logic (i.e., subtasks) will be detailed in subsequent embodiments.

[0038] The following describes step 203, namely "determining the sub-task of the code development task corresponding to the target event", in detail with reference to the embodiments.

[0039] The term "code development task" as used in the public context refers to a complete automated processing request initiated by a user (e.g., a developer) within a development system (or automated coding system). This request is based on user-inputted development requirements, which include core business requirements, technology stack and architectural constraints, functional details, and boundary conditions. A code development task must at least include a unique task identifier, development requirements information, the product line or project to which it belongs, and a configured workspace path.

[0040] In this step, at least one type of event queue contains events related to code development tasks, typically events generated in response to user input or feedback during the process from the creation of the code development task to its completion.

[0041] To facilitate understanding, the processing of code development tasks is first briefly described. As one possible implementation, a preferred code development task may include: after obtaining development requirement information input by the user, invoking a first coding agent (also called a programming agent) to generate execution plan information based on the development requirement information, and sending the execution plan information to the user terminal. If feedback from the user terminal indicates rejection of the execution plan information, then obtaining at least one of the rejection reason and modification suggestion returned by the user terminal, invoking the first coding agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestion, as well as the development requirement information. If feedback from the user terminal indicates confirmation of the execution plan information, then invoking a second coding agent to generate code based on the development requirement information and the execution plan information. The code is submitted for review. If the review result indicates rejection, then the second coding agent is invoked to optimize the code based on the development requirement information, the execution plan information, and the review feedback information for the code; then the optimized code is submitted for review again until the review result is approval.

[0042] Besides the methods described above, in the code development task, instead of sending the execution plan information to the user end, the second coding agent can be directly invoked to generate code based on the development requirements information and the generated execution plan information. Alternatively, the code development task can be terminated directly after code generation without submitting the code for review.

[0043] Therefore, based on the above code development tasks, in some scenarios, the target event is the new task event of the code development task. Then, the sub-tasks of the code development task corresponding to the target event determined by the scheduler instance include: calling the first coding agent to generate execution planning information based on the development requirements information, and sending the execution planning information to the user terminal.

[0044] The term "coding agent" as used in this disclosure refers to an intelligent programming agent built on a large language model, capable of understanding development requirements and generating execution specifications or code—a software module or service. Its core function is to understand and execute processing logic related to writing code.

[0045] In other scenarios, the target event is the event in which the user returns confirmation of the execution plan information. In this case, the sub-tasks of the code development task corresponding to the target event determined by the scheduler instance include: calling the second coding agent to generate code based on the development requirements information and the confirmed execution plan information, and submitting the code for review.

[0046] In some other scenarios, the target event is the event in which the user returns a rejection of the execution plan information. In this case, the subtasks of the code development task corresponding to the target event determined by the scheduler instance include: obtaining at least one of the rejection reason and modification suggestion, calling the first coding agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestion and the development requirement information, and sending the execution plan information to the user.

[0047] In some other scenarios, the target event is an event indicating rejection in the code review result. In this case, the sub-tasks of the code development task corresponding to the target event determined by the scheduler instance include: obtaining review feedback information for the code, calling the second coding agent to optimize the code based on the development requirements information, execution planning information and review feedback information for the code, and submitting the optimized code for review.

[0048] By mapping different types of events such as creating new tasks, confirming execution plan information, rejecting execution plan information, and code review results indicating rejection to the sub-tasks triggered in the above scenarios, different types of events are mapped to specific processing logic that the executor instance can execute, making the entire end-to-end process from development requirements information to code clear, controllable, and traceable.

[0049] Depending on the different phases included in the code development task, the above target events and their corresponding sub-tasks may also be other contents or forms, which will not be listed here.

[0050] The following describes in detail step 205, namely "selecting an executor instance from multiple executor instances and assigning the subtasks of the code development task corresponding to the target event to the selected executor instance", with reference to the embodiments.

[0051] When selecting executor instances, their status can be determined, and only those instances that are alive can be chosen. The scheduler instance can use a periodic heartbeat mechanism to check the status of executor instances, i.e., whether an executor instance is alive or invalid. Typically, when an executor instance becomes invalid, the resources it occupies will be cleaned up and reclaimed; for example, local session files will be deleted.

[0052] In this embodiment of the disclosure, the failure of the executor instance is not limited to the executor instance crashing or stopping, but can also be due to excessive load, insufficient resources, etc.

[0053] Furthermore, if an executor instance is detected to be in a failed state due to not completing its assigned subtask, the assigned subtask is marked as failed, or the assigned subtask is reassigned. During reassignment, the subtask can be repackaged into an event and placed back into the event queue, awaiting reassignment by the scheduler instance.

[0054] In this way, the scheduler instance can proactively discover failed executor instances and mark the unfinished subtasks of the failed executor instances as failed or reassign them, preventing subtasks from being suspended indefinitely due to unexpected executor instance crashes, and further improving the robustness and reliability of the auto-coding system.

[0055] One possible approach is for each executor instance, upon startup, to send heartbeat information to a shared registry at fixed time intervals (e.g., once per second). This heartbeat information includes at least the instance ID and the latest timestamp. The scheduler instance uses the heartbeat information stored in the registry to determine whether the executor instances are alive. For example, if the difference between the latest timestamp of an executor instance and the current time exceeds a preset threshold (e.g., 30 seconds), the executor instance is considered to be in a failed state.

[0056] Since a code development task may include multiple subtasks, and these subtasks have contextual relationships, this disclosure provides a preferred allocation strategy to optimize execution efficiency and improve the coherence and efficiency of the code development task. In this disclosure, if the subtask corresponding to the target event does not have a preceding subtask belonging to the same code development task, or if the executor instance executing the preceding subtask (referred to as the first executor instance in this disclosure) is in a failed state, then based on the load status of the multiple executor instances, a second executor instance is selected from the multiple executor instances, and the subtask corresponding to the target event is allocated to the second executor instance; if the first executor instance executing the preceding subtask is alive, then the subtask corresponding to the target event is allocated to the first executor instance.

[0057] If subtask a and subtask b belong to the same code development task, subtask a is executed before subtask b, and there is a dependency relationship between subtask a and subtask b, then subtask a is considered to be the preceding subtask of subtask b.

[0058] This implementation method ensures that different subtasks of the same code development task are assigned to the same executor instance for execution as much as possible. In this way, the executor instance can directly process based on the context of the preceding subtask, thereby improving the coherence and efficiency of task execution.

[0059] When selecting a second executor instance from multiple executor instances, the subtask can be distributed to a suitable executor instance based on the real-time load status of the executor instance cluster, thereby achieving load balancing and efficient resource utilization.

[0060] One possible approach is to maintain an executor resource pool containing idle executor instances that are currently active. The scheduler instance can retrieve an idle executor instance from the pool and assign a subtask of the code development task corresponding to the target event to that idle executor instance. After executing the assigned subtask, the executor instance returns to the executor resource pool.

[0061] An executor resource pool is a logical management concept used to maintain a list of currently idle executor instances (those that have not been assigned subtasks or have low resource consumption). After an executor instance finishes executing its assigned subtask, it returns to the executor resource pool, awaiting its next allocation. This approach reuses executor resources through pooling technology, avoiding the overhead of frequently creating and destroying executor instances for each task. By adopting this executor resource pooling management method, rapid matching and efficient reuse of executor instances can be achieved, reducing the complexity of task allocation.

[0062] Besides using an executor resource pool, other methods can be used to select executor instances based on load conditions. For example, based on the load condition of the executor instance, the executor instance with the fewest currently processing subtasks can be selected; or, the executor with the lowest CPU utilization, memory usage, or overall load can be selected.

[0063] To ensure the consistency of the task context during fault recovery and task retries, embodiments of this disclosure also introduce a task identifier and allocation information management mechanism. Specifically, it includes recording the subtask allocation information of the executor instance. This subtask allocation information includes the task identifier of the code development task corresponding to the allocated subtask, and may also include information such as the executor instance identifier, allocation time, and subtask status. If an executor instance is detected to be in a failed state, the subtask allocation information of the failed executor instance is cleared.

[0064] By querying the subtask allocation information of each executor instance, the first executor instance for executing the preceding subtask can be determined. For example, if the target event carries a task identifier for a code development task, the subtask allocation identifier of each executor instance can be queried using the task identifier of the target event to determine that the executor instance corresponding to the subtask allocation identifier containing that task identifier is the aforementioned first executor instance.

[0065] Subtask allocation information can maintain the mapping relationship between subtasks and executor instances of a code development task, thereby facilitating the acquisition of global allocation information for the code development task. Furthermore, it can promptly clear the corresponding subtask allocation information after the executor instance becomes invalid, thus making the subtask allocation status of the code development task more accurate.

[0066] To ensure that subtasks reassigned to a second executor instance can still access the necessary context when the first executor instance fails, embodiments of this disclosure further provide a session persistence and synchronization mechanism. Specifically, the session content generated when an executor instance calls a coded agent to execute a subtask is recorded in a local session file; in response to detecting a change in the local session file, the modified local session file is synchronized to a remote storage space, such as a cloud server.

[0067] The session file may include, but is not limited to, globally unique identifiers (usually uniquely corresponding to code development tasks), user-provided raw input (such as user-inputted development requirements, user feedback on execution planning information, user feedback on code review results, etc.), the coding agent's thought records, and the coding agent's output content, among other contextual content. The session file corresponds to the code development task; for example, the task identifier of the code development task is maintained and stored in correspondence with the identifier in the session file. Subtasks at each stage of the code development task share the same task identifier, thus distinguishing which code development task they belong to.

[0068] In this embodiment of the disclosure, the session management module can periodically detect the local session files corresponding to the code development task through a session listener. The session listener can be bound to the code development task identifier. The interval of periodic detection can be flexibly configured, for example, set to 30 seconds, 1 minute, or a shorter or longer time interval, to capture changes in session content.

[0069] One possible approach is for the session listener to periodically check the most recent modification timestamp of the session file and determine whether the local session file has been changed by comparing the modification timestamp with the timestamp of the last time the session file was synchronized to the remote storage space.

[0070] Besides this method, other methods can be used to detect whether local session files have changed, such as listening for file modification events through the operating system's file system monitoring interface.

[0071] The aforementioned synchronization operation may include reading the modified session file and uploading it to a specified path in a remote storage space (such as cloud storage) via a network protocol. For example, it may involve creating an export directory structure, parsing the session content in the session file, organizing and converting the session content according to a predefined format to generate a viewable document, and uploading it to the specified storage path in the remote storage space. This storage path is associated with the task identifier of the code development task to ensure that the session content of each code development task can be accurately stored and retrieved, and to guarantee the security and accessibility of the session content. If the upload is successful, the timestamp of the session file synchronized to the remote storage space is updated.

[0072] Synchronization can take the form of, but is not limited to, full synchronization and incremental synchronization. Full synchronization refers to uploading the entire session file every time a change is detected in the local session file. Incremental synchronization refers to appending only the newly added lines or data blocks from the local session file to the session file in the remote storage space.

[0073] Based on this, when the scheduler instance assigns a subtask to the second executor instance, it can send the task identifier of the code development task to the second executor instance, so that the second executor instance can retrieve the session file corresponding to the code development task from the remote storage space based on the task identifier to execute the assigned subtask.

[0074] Alternatively, when the scheduler instance assigns a subtask to the second executor instance, it can first determine the storage path information of the remote storage space corresponding to the task identifier based on the task identifier, and send the storage path information to the second executor instance so that the second executor instance can obtain the session file corresponding to the code development task from the remote storage space based on the storage path information to execute the assigned subtask.

[0075] This approach ensures the continuity and recoverability of the code development task execution process. Even if different subtasks of the same code development task are assigned to different executor instances, the subtasks can continue to be executed based on a unified session context, thus improving the robustness and fault tolerance of the system.

[0076] For example, for a subtask corresponding to a newly created task event, since this subtask is the first subtask of the code development task, there is no related subtask allocation record yet. This subtask is assigned to executor instance 'a', which then calls the first coding agent to generate execution plan information based on development requirements and sends the execution plan information to the user client. The subtask allocation record of executor instance 'a' contains the identifier of the code development task, subtask information, etc. Additionally, the session management module maintains the session files for the code development task and synchronizes them to remote storage space (e.g., a cloud server) in a timely manner.

[0077] If the user confirms the execution plan information, the auto-coding system will receive a confirmation event from the user. This event carries an identifier for the code development task. Using this identifier, the system can find the subtasks executed by executor instance a. If executor instance a is still alive, the subtask corresponding to the confirmation event will be reassigned to executor instance a. Executor instance a will then call the second coding agent to generate code based on the development requirements and the confirmed execution plan information, and submit the code for review. The subtask assignment record for executor instance a will continue to record the subtask identifiers, etc. Additionally, the session management module continues to maintain the session files for the code development tasks and synchronizes them to remote storage in a timely manner.

[0078] If executor instance a fails at this time, the subtask allocation information of executor instance a will be cleared.

[0079] If the code review result is "rejected," the automatic coding system will receive a "code review rejection" event, which carries the identifier of the code development task. Since the subtask allocation information of executor instance a is cleared, the identifier of this code development task cannot be used to find any executor instances that previously processed the subtask and are still alive. Therefore, the scheduler instance, based on the load status of the executor instances, reallocates executor instance b to execute the subtask corresponding to the "code review rejection" event, and passes the task identifier of the code development task to executor instance b. Executor instance b, based on the task identifier of the code development task, pulls the session file of the code development task from remote storage. This file contains user-inputted development requirements, confirmed execution plan information, and the session content such as the code previously generated by executor instance a. Executor instance b uses this session content as context to obtain review feedback information for the code, calls the second coding agent to optimize the code based on the development requirements information, execution plan information, and review feedback information, and submits the optimized code for review.

[0080] Figure 3 This is a schematic block diagram of a task scheduling device provided in an embodiment of the present disclosure. It is applied to an automatic coding system including multiple scheduler instances and multiple executor instances. The task scheduling device runs on a scheduler instance, such as... Figure 3 As shown, the task scheduling device 300 may include: an event acquisition unit 301, a task determination unit 302, and a task allocation unit 303. It may also include a status detection unit 304, a task management unit 305, and a record maintenance unit 306. The main functions of each component are as follows: The event acquisition unit 301 is configured to acquire a target event from at least one type of event queue through a distributed lock mechanism, wherein the target event is acquired by one of a plurality of scheduler instances.

[0081] The task determination unit 302 is configured to determine the subtask of the code development task corresponding to the target event.

[0082] The task allocation unit 303 is configured to select an executor instance from the multiple executor instances based on the load status of the multiple executor instances, and allocate the subtask of the code development task corresponding to the target event to the selected executor instance.

[0083] As one possible implementation, the event acquisition unit 301 can be configured as follows: Request a queue-level lock for the target queue containing the target event, retrieve the target event from the target queue, and release the queue-level lock; or, Request an event-level lock for the target event, retrieve the target event from the target queue where the target event is located, and release the event-level lock.

[0084] Furthermore, the status detection unit 304 can be configured to detect the status of the executor instance of the assigned subtask through a heartbeat mechanism.

[0085] The task management unit 305 can be configured to mark the assigned subtask as a failure state if the status detection unit 304 detects that the executor instance has not completed the assigned subtask and is in a failure state, or to reassign the assigned subtask.

[0086] As one possible implementation method, the task allocation unit 303 can be specifically configured as follows: if the subtask corresponding to the target event does not have a preceding subtask belonging to the same code development task, or if the first executor instance executing the preceding subtask is in a failed state, then based on the load status of multiple executor instances, a second executor instance is selected from multiple executor instances, and the subtask corresponding to the target event is allocated to the second executor instance; if the first executor instance executing the preceding subtask is in a live state, then the subtask corresponding to the target event is allocated to the first executor instance.

[0087] As one possible implementation method, when the task allocation unit 303 selects a second executor instance from multiple executor instances based on the load status of multiple executor instances, it can be specifically configured to: select an executor instance from the executor resource pool as the second executor instance, the executor resource pool including idle executor instances that are alive; wherein, after the second executor instance finishes executing the assigned sub-task, it returns to the executor resource pool.

[0088] Furthermore, the record maintenance unit 306 can be configured to: record the subtask allocation information of each executor instance; if the status detection unit 304 detects that an executor instance is in a failed state, clear the subtask allocation information of the executor instance in the failed state.

[0089] The task allocation unit 303 can also be configured to query the subtask allocation information of each executor instance to determine the first executor instance to execute the preceding subtask.

[0090] As one possible approach, the target event carries a task identifier for the code development task.

[0091] When assigning a subtask corresponding to a target event to a second executor instance, the task allocation unit 303 can be specifically configured to send the task identifier or the storage path information of the remote storage space corresponding to the task identifier to the second executor instance, so that the second executor instance can obtain the session file corresponding to the code development task from the remote storage space based on the task identifier or storage path information to execute the assigned subtask.

[0092] The session files stored in the remote storage space are synchronized from the session files stored locally by the first executor instance. The session files include the session content generated when the first executor instance calls the coding agent to execute subtasks of the code development task.

[0093] When determining the subtasks of the code development task corresponding to the target event, the task determination unit 302 may specifically execute at least one of the following: If the target event is a new task event of the code development task, then the sub-task of the code development task corresponding to the target event includes: calling the first coding agent to generate execution plan information based on development requirement information, and sending the execution plan information to the user terminal; If the target event is a confirmation of execution plan information returned by the user, then the sub-task of the code development task corresponding to the target event includes: calling the second coding agent to generate code based on the development requirements information and the confirmed execution plan information, and submitting the code for review; If the target event is an event in which the user returns a rejection of the execution plan information, then the sub-tasks of the code development task corresponding to the target event include: obtaining at least one of the rejection reason and modification suggestion, calling the first coding agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestion and the development requirement information, and sending the execution plan information to the user. If the target event is a code review result indicating rejection, then the sub-tasks of the code development task corresponding to the target event include: obtaining review feedback information for the code, calling the second coding agent to optimize the code based on development requirement information, execution planning information and review feedback information for the code, and submitting the optimized code for review.

[0094] The technical solutions disclosed herein involve the collection, storage, use, processing, transmission, provision, and disclosure of information such as user personal information, all of which comply with relevant laws and regulations and do not violate public order and good morals.

[0095] This disclosure also provides an electronic device, including: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the task scheduling method described in any of the foregoing method embodiments.

[0096] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute the task scheduling method described in any of the foregoing method embodiments.

[0097] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the task scheduling method described in any of the foregoing method embodiments.

[0098] Figure 4 A schematic block diagram of an example electronic device 400 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0099] like Figure 4As shown, device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 402 or a computer program loaded from storage unit 408 into random access memory (RAM) 403. RAM 403 may also store various programs and data required for the operation of device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0100] Multiple components in device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of monitors, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0101] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above, such as task scheduling methods. For example, in some embodiments, the task scheduling method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program may be loaded and / or installed on device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of the task scheduling method described above may be performed. Alternatively, in other embodiments, the computing unit 401 may be configured to perform task scheduling methods by any other suitable means (e.g., by means of firmware).

[0102] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0103] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0104] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0105] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0106] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0107] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0108] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0109] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A task scheduling method, characterized by, The method includes: A target event is retrieved from an event queue of at least one type using a distributed lock mechanism, wherein the target event is retrieved by one of multiple scheduler instances; Determine the subtasks of the code development task corresponding to the target event; Select an executor instance from multiple executor instances, and assign the subtask of the code development task corresponding to the target event to the selected executor instance.

2. The method of claim 1, wherein, The step of retrieving the target event from at least one type of event queue using a distributed lock mechanism includes: Request a queue-level lock for the target queue containing the target event, and release the queue-level lock after retrieving the target event from the target queue; or, Request an event-level lock for the target event, and release the event-level lock after retrieving the target event from the target queue where the target event is located.

3. The method according to claim 1, further comprising: The status of the executor instance of the assigned subtask is detected by a heartbeat mechanism. If the executor instance is found to be in an invalid state because it has not completed the assigned subtask, the assigned subtask is marked as a failure, or the assigned subtask is reassigned.

4. The method of any one of claims 1 to 3, wherein, The step of selecting an executor instance from multiple executor instances and assigning the subtask of the code development task corresponding to the target event to the selected executor instance includes: If the subtask corresponding to the target event does not have a preceding subtask belonging to the same code development task, or if the first executor instance executing the preceding subtask is in a failed state, then based on the load status of the multiple executor instances, a second executor instance is selected from the multiple executor instances, and the subtask corresponding to the target event is assigned to the second executor instance. If the first executor instance executing the preceding subtask is alive, the subtask corresponding to the target event is assigned to the first executor instance.

5. The method of claim 4, wherein, The step of selecting a second actuator instance from the plurality of actuator instances based on their load status includes: An executor instance is selected from the executor resource pool as the second executor instance, the executor resource pool including idle executor instances that are alive; The second executor instance returns to the executor resource pool after completing the assigned subtask.

6. The method of claim 4, wherein, The method further includes: Record the subtask allocation information for each executor instance; If an executor instance is detected to be in a failed state, clear the subtask assignment information of the failed executor instance. Query the subtask allocation information of each executor instance to determine the first executor instance to execute the preceding subtask.

7. The method of claim 4, wherein, The target event carries the task identifier of the code development task; Assigning the subtask of the code development task corresponding to the target event to the selected executor instance includes: The task identifier or the storage path information of the remote storage space corresponding to the task identifier is sent to the second executor instance so that the second executor instance can obtain the session file corresponding to the code development task from the remote storage space based on the task identifier or the storage path information to execute the assigned sub-task; The session files stored in the remote storage space are synchronized from the session files stored locally by the first executor instance. The session files include the session content generated when the first executor instance calls the coding agent to execute the sub-tasks of the code development task.

8. The method of any one of claims 1 to 3, wherein, The subtask for determining the code development task corresponding to the target event includes at least one of the following: If the target event is a new task event of the code development task, then the sub-task of the code development task corresponding to the target event includes: calling the first coding agent to generate execution plan information based on development requirement information, and sending the execution plan information to the user terminal; If the target event is a confirmation of execution plan information returned by the user, then the sub-task of the code development task corresponding to the target event includes: calling the second coding agent to generate code based on the development requirements information and the confirmed execution plan information, and submitting the code for review; If the target event is an event in which the user returns a rejection of the execution plan information, then the sub-task of the code development task corresponding to the target event includes: obtaining at least one of the rejection reason and modification suggestion, calling the first coding agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestion and the development requirement information, and sending the execution plan information to the user. If the target event is a code review result indicating rejection, then the sub-tasks of the code development task corresponding to the target event include: obtaining review feedback information for the code, invoking the second coding agent to optimize the code based on development requirement information, execution planning information and review feedback information for the code, and submitting the optimized code for review.

9. An automatic coding system characterized in that, The system includes multiple scheduler instances and multiple executor instances; The scheduler instance is configured to retrieve target events from at least one type of event queue via a distributed lock mechanism; Determine the subtasks of the code development task corresponding to the target event; Select an executor instance from the plurality of executor instances, and assign the subtask of the code development task corresponding to the target event to the selected executor instance; The executor instance is configured to execute subtasks assigned by the scheduler instance.

10. A task scheduling apparatus characterized by comprising: The task scheduling device includes: An event acquisition unit is configured to acquire a target event from at least one type of event queue via a distributed lock mechanism, wherein the target event is acquired by one of a plurality of scheduler instances; The task determination unit is configured to determine a subtask of the code development task corresponding to the target event; The task allocation unit is configured to select an executor instance from a plurality of executor instances and allocate the subtasks of the code development task corresponding to the target event to the selected executor instance.

11. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

12. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-8.

13. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-8.

Images