RPA task execution retry optimization method based on machine learning

Abstract

The invention discloses an RPA task execution retry optimization method based on machine learning, and relates to the technical field of machine learning, an external tool is not needed, a developer can directly complete debugging in a browser, front-end and back-end real-time communication is achieved through the WebSocket technology, the developer can monitor the execution state of each process link in real time, and the execution efficiency is improved. Therefore, fine-grained control is carried out on the process anytime and anywhere; besides, global variables and the capability of skipping to any link are modified in real time, so that a developer can quickly verify different logic branches under the condition of not restarting a process; most importantly, the system and a low-code designer are seamlessly integrated, and design, debugging and operation are simultaneously carried out in a unified interface, so that the switching cost in the development process is reduced, the whole development, test and debugging process is smoother, and the development efficiency and experience are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of machine learning, and in particular to an RPA task execution retry optimization method based on machine learning. Background Art

[0002] The low-code designer real-time debugging system is an upper-level device based on the low-code designer. The low-code designer is implemented based on a Web browser. It can perform low-code business logic development by dragging links to the editor. The links include logical links: if conditions, loops, jumping out of loops, assignments, etc., and data links: adding, modifying, deleting, querying, etc. The process links include: calling sub-processes, calling java services, etc., and the combination of links is used to replace code development.

[0003] Usually, code debugging requires installing additional devices and configuring the corresponding complete environment for the devices. The whole process has a high threshold and a steep learning curve. Alternatively, the program execution log can be analyzed to determine whether the code execution is correct based on the information in the execution log. However, this method is inefficient and it is difficult to observe the situation at each step of the execution process. Summary of the invention

[0004] The purpose of the present invention is to provide an RPA task execution retry optimization method based on machine learning to solve the problems raised in the prior art.

[0005] To achieve the above object, the present invention provides the following technical solution: an RPA task execution retry optimization method based on machine learning, the optimization method comprising:

[0006] Step S1: collecting debugging records of each successful code debugging in the system, wherein each debugging record includes the code set as sample data and the code step corresponding to the breakpoint set as target data;

[0007] The sample data consists of four basic structures, which are variables and data types, operators, control structures, and functions.

[0008] Step S2: the system analyzes the debugging record and constructs a breakpoint recommendation table;

[0009] Step S3: The system's Web client establishes a connection with the server;

[0010] Step S4: the Web client executes the start debugging operation, the system queries the breakpoint recommendation table to automatically set the breakpoint, and transmits the breakpoint data to the server;

[0011] Step S5: After receiving the breakpoint data, the server debugs the code according to the breakpoint data and transmits the real-time debugging information to the Web client;

[0012] Step S6: The Web client receives the real-time debugging information, and renders the currently executed steps and refreshes the global variables according to the debugging information.

[0013] Furthermore, in step S2, the debugging record is analyzed to construct a breakpoint recommendation table:

[0014] Step S2-1: number the four basic structures, divide the sample data in each debugging record according to the four basic structures and mark them with corresponding numbers, run the sample data to output a number sequence, the number sequence is the execution path of the sample data, and count the execution paths of the sample data in all debugging records to form a set Y={y 1 ,y 2 ,...,y n}, where y n Indicates the nth execution path;

[0015] Step S2-2: Mark the target data in the sample data in each debugging record, and mark the previous step of the target data with a first label a i , label the next step of the target data with a second label b i , forming the coordinate m i =(a i ,b i ), the m i The breakpoint positions of the sample data are counted, and the breakpoint positions of the sample data in all debugging records are counted to form a set M = {m 1 ,m 2 ,...m n}, where m n Indicates the breakpoint position corresponding to the nth execution path;

[0016] Step S2-3: According to the execution path Y={y 1 ,y 2 ,...,y n} and breakpoint position M = {m 1 ,m 2 ,...m n}, extract all execution paths corresponding to the same breakpoint position, forming a set y = {y 1 ,y 2 ,...y k}, where set y is a subset of set Y;

[0017] Step S2-4: Calculate the execution path y σ Under the condition that a breakpoint position m is executed iThe probability of being set is calculated according to the formula:

[0018]

[0019] in,

[0020] Among them, P(y σ |m i ) is at the breakpoint position m i Execute path y under the condition σ The probability of being executed, N y is the breakpoint position m i The number of records of the corresponding execution path y in the set Y, N yσ Execute path y σ The number of records in set y; P(m i ) is the m in all breakpoint positions i The probability of being set, N M is the number of records of all breakpoint positions in the set M, N mi is the breakpoint position m i The number of records in the set M; P(y σ ) is y in all execution paths σ The probability of being executed, N Y is the number of records of all execution paths in set Y, N yσ Execute path y σ The number of records in set Y;

[0021] Step S2-5: Counting the probability of each breakpoint position being set under the same execution path, and using a comparator to screen out the breakpoint position with the highest probability of being set, and using the breakpoint position with the highest probability of being set as the recommended breakpoint position corresponding to the execution path;

[0022] Step S2-6: statistics are collected for each execution path and the recommended breakpoint position corresponding to each execution path, wherein each execution path and the recommended breakpoint position corresponding to each execution path are arranged in a row, and a breakpoint position recommendation table is constructed.

[0023] Furthermore, in step S3, the system's Web client establishes a persistent connection with the server through WebSocket technology, and creates a unique Session Id flag for the persistent connection.

[0024] Further, the operations of the Web client interface in step S4 include starting debugging, viewing and editing global variable values, setting breakpoints, continuing execution, stepping execution, and ending debugging;

[0025] Furthermore, in step S4, the process of the system querying the breakpoint recommendation table to automatically set the breakpoint includes:

[0026] Step S4-1: The Web client executes a startup debugging operation;

[0027] Step S4-2: the system recognizes that a debugging operation is started, and traverses the breakpoint recommendation table to search for an execution path that matches the current code;

[0028] Step S4-3: The Web client executes a breakpoint setting operation, and the system automatically sets a breakpoint for the code according to the recommended breakpoint position corresponding to the execution path in the breakpoint recommendation table;

[0029] Step S4-4: The Web client transmits the breakpoint data to the server through a long connection.

[0030] Further, in step S5, after the server receives the breakpoint data sent by the Web client, a Debug interceptor is registered in the code execution engine of the server, and the Debug interceptor is used to generate a Debug context and control code debugging according to the Debug context, wherein the Debug context is bound to the Session Id;

[0031] Furthermore, the debug context is composed of fields, including breakpoints, stepOver, breaker, messageChannel, changeGlobalsData, and gotoStep;

[0032] Among them, breakpoints is used to store breakpoint data transmitted by the Web client, messageChannel is a message channel used to transmit real-time debugging information to the Web client, changeGlobalsData is the global variable change data, and gotoStep is the jump step;

[0033] Among them, breakpoints includes the fields flowId and stepId. The field flowId is the process id, which is used to store the breakpoint data set in the process. The field stepId is the code step id, which is used to store the breakpoint data set at the code step.

[0034] stepOver is a stepping flag, where stepOver includes true and false. True means stepping, and the code needs to be executed from the current step to the next step and paused. False means non-stepping, and the code continues to execute from the current step without pausing.

[0035] Breaker is a blocking controller. Breaker includes task operation and free operation. Task operation is used to block thread execution, and free operation is used to release the blockage and allow the thread to continue execution.

[0036] Furthermore, the process of controlling code debugging according to the Debug context includes:

[0037] Step S5-1: The server creates a new thread to execute the code, and the Debug interceptor starts to take effect, and the Debug interceptor starts to execute before each step of the code is executed;

[0038] Step S5-2: The server inputs each step of the code into the Debug interceptor. When the Web client performs a step-by-step execution operation, stepOver in the Debug context becomes true, or when the breakpoint data contained in the breakpoints field in the Debug context includes the currently executed step, the breaker in the Debug context executes the task operation to block the thread execution. When the Web client performs a continue execution operation, the breaker in the Debug context executes the free operation to release the blockage and allow the thread to continue execution.

[0039] Step S5-3: After the breaker executes the free operation to release the blockage, the server synchronizes the changeGlobalsData in the Debug context to the global variables of the code execution;

[0040] Step S5-4: The Debug interceptor checks whether the gotoStep in the Debug context is set in the code, and if gotoStep is set, jumps to the step where the gotoStep is set to continue execution;

[0041] Step S5-5: the server sends real-time debugging information to the Web client through the messageChannel in the Debug context;

[0042] Furthermore, in step S5-4, the process of the Debug interceptor checking whether the gotoStep in the Debug context is set in the code includes:

[0043] First, the step stack is initialized, all steps are put into the initialized stack, and then the step at the top of the stack is popped out, and it is checked whether the step at the top is the gotoStep step. If it is not the gotoStep step, the steps at the top of the stack are continuously popped out until it is the gotoStep step.

[0044] Compared with the prior art, the present invention has the following beneficial effects:

[0045] 1. There is no need to configure an IDE or use special debugging tools; the debugging function is fully integrated in the low-code designer. You can design, debug and run business processes by simply opening a browser; this seamless integration reduces switching between tools and improves work efficiency.

[0046] 2. Real-time communication based on WebSocket enables information such as process execution status, current link, and variable changes to be pushed to the browser interface in real time. Developers can dynamically monitor and adjust the process, and modify global variables or jump to different links in real time during debugging, avoiding multiple restarts of the process to verify different logics.

[0047] 3. Traditional logging methods rely on recording a large amount of information, and developers often need to repeatedly check and filter logs to locate problems. In-browser debugging, through breakpoints and single-step execution, allows developers to accurately control the execution process, avoiding the tedious steps of searching for error clues from massive logs.

[0048] 4. Since debugging is completely based on the browser, developers can operate on any device without being bound to a specific development environment; this is especially suitable for remote collaboration and mobile office scenarios, and developers can debug and verify processes anytime and anywhere. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 is a flow chart of the method of the present invention;

[0050] Figure 2 This is a schematic diagram of the Web client user interface of the present invention;

[0051] Figure 3 It is a schematic diagram of the interaction between the Web client and the server of the present invention. DETAILED DESCRIPTION

[0052] Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in the field without making any creative work shall fall within the scope of protection of the present invention.

[0053] Example: Figure 1-Figure 3 As shown, the present invention provides a technical solution, a RPA task execution retry optimization method based on machine learning, and the optimization method includes:

[0054] Step S1: collecting debugging records of each successful code debugging in the system, wherein each debugging record includes the code set as sample data and the code step corresponding to the breakpoint set as target data;

[0055] The sample data consists of four basic structures, which are variables and data types, operators, control structures, and functions.

[0056] Step S2: the system analyzes the debugging record and constructs a breakpoint recommendation table;

[0057] The process of analyzing the debugging record in step S2 and constructing a breakpoint recommendation table includes:

[0058] Step S2-1: number the four basic structures, divide the sample data in each debugging record according to the four basic structures and mark them with corresponding numbers, run the sample data to output a number sequence, the number sequence is the execution path of the sample data, and count the execution paths of the sample data in all debugging records to form a set Y={y 1 ,y 2 ,...,y n}, where y n Indicates the nth execution path;

[0059] Step S2-2: Mark the target data in the sample data in each debugging record, and mark the previous step of the target data with a first label a i , label the next step of the target data with a second label b i , forming the coordinate m i =(a i ,b i ), the m i The breakpoint positions of the sample data are counted, and the breakpoint positions of the sample data in all debugging records are counted to form a set M = {m 1 ,m 2 ,...m n}, where m n Indicates the breakpoint position corresponding to the nth execution path;

[0060] Step S2-3: According to the execution path Y={y 1 ,y 2 ,...,y n} and breakpoint position M = {m 1 ,m 2 ,...m n}, extract all execution paths corresponding to the same breakpoint position, forming a set y = {y 1 ,y 2 ,...y k}, where set y is a subset of set Y;

[0061] Step S2-4: Calculate the execution path y σ Under the condition that a breakpoint position m is executed i The probability of being set is calculated according to the formula:

[0062]

[0063] in,

[0064] Among them, P(y σ |m i ) is at the breakpoint position m i Execute path y under the condition σ The probability of being executed, N y is the breakpoint position m i The number of records of the corresponding execution path y in the set Y, N yσ Execute path y σ The number of records in set y; P(m i ) is the m in all breakpoint positions i The probability of being set, N M is the number of records of all breakpoint positions in the set M, N mi is the breakpoint position m i The number of records in the set M; P(y σ ) is y in all execution paths σ The probability of being executed, N Y is the number of records of all execution paths in set Y, N yσ Execute path y σ The number of records in set Y;

[0065] Step S2-5: Counting the probability of each breakpoint position being set under the same execution path, and using a comparator to screen out the breakpoint position with the highest probability of being set, and using the breakpoint position with the highest probability of being set as the recommended breakpoint position corresponding to the execution path;

[0066] Step S2-6: statistics are collected for each execution path and the recommended breakpoint position corresponding to each execution path, wherein each execution path and the recommended breakpoint position corresponding to each execution path are arranged in a row, and a breakpoint position recommendation table is constructed.

[0067] In an embodiment of the present invention, a developer performs code debugging on a Web client. After each successful debugging, the system automatically collects debugging records, which include code sample data and code steps (target data) corresponding to breakpoints. The code sample data is composed of four basic structures, namely, variables and data types, operators, control structures, and functions. The system numbers these structures and constructs an execution path for the sample data. The system stores the execution path for the sample. Then, the system stores the breakpoint position coordinates, and there is a one-to-one correspondence between the breakpoint position coordinates and the execution path.

[0068] Step S3: The system's Web client establishes a connection with the server;

[0069] Among them, in step S3, the system's Web client establishes a persistent connection with the server through WebSocket technology and creates a unique Session Id mark for the persistent connection.

[0070] Step S4: the Web client executes the start debugging operation, the system queries the breakpoint recommendation table to automatically set the breakpoint, and transmits the breakpoint data to the server;

[0071] The operations of the Web client interface in step S4 include starting debugging, viewing and editing global variable values, setting breakpoints, continuing execution, stepping execution, and ending debugging.

[0072] The process of the system querying the breakpoint recommendation table and automatically setting the breakpoint in step S4 includes:

[0073] Step S4-1: The Web client executes a startup debugging operation;

[0074] Step S4-2: the system recognizes that a debugging operation is started, and traverses the breakpoint recommendation table to search for an execution path that matches the current code;

[0075] Step S4-3: The Web client executes a breakpoint setting operation, and the system automatically sets a breakpoint for the code according to the recommended breakpoint position corresponding to the execution path in the breakpoint recommendation table;

[0076] Step S4-4: The Web client transmits the breakpoint data to the server through a long connection.

[0077] Step S5: After receiving the breakpoint data, the server debugs the code according to the breakpoint data and transmits the real-time debugging information to the Web client;

[0078] Among them, after the server receives the breakpoint data sent by the Web client in step S5, a Debug interceptor is registered in the code execution engine of the server, and the Debug interceptor is used to generate a Debug context and control code debugging according to the Debug context, wherein the Debug context is bound to the Session Id.

[0079] The debug context is composed of fields, including breakpoints, stepOver, breaker, messageChannel, changeGlobalsData, and gotoStep.

[0080] breakpoints is used to store breakpoint data transmitted by the Web client, the messageChannel is a message channel used to transmit real-time debugging information to the Web client, the changeGlobalsData is global variable change data, and the gotoStep is a jump step;

[0081] Wherein, breakpoints includes fields flowId and stepId. The field flowId is the process id, which is used to store the breakpoint data set in the process. The field stepId is the code step id, which is used to store the breakpoint data set at the code step.

[0082] stepOver is a stepping flag, wherein stepOver includes true and false. True represents stepping, and the code needs to be executed from the current step to the next step and paused. False represents non-stepping, and the code continues to execute from the current step without pausing.

[0083] A breaker is a blocking controller, wherein the breaker includes a task operation and a free operation. The task operation is used to block the execution of a thread, and the free operation is used to release the blockage and allow the thread to continue executing.

[0084] The process of controlling code debugging according to the Debug context includes:

[0085] Step S5-1: The server creates a new thread to execute the code, and the Debug interceptor starts to take effect, and the Debug interceptor starts to execute before each step of the code is executed;

[0086] Step S5-2: The server inputs each step of the code into the Debug interceptor. When the Web client performs a step-by-step execution operation, stepOver in the Debug context becomes true, or when the breakpoint data contained in the breakpoints field in the Debug context includes the currently executed step, the breaker in the Debug context executes the task operation to block the thread execution. When the Web client performs a continue execution operation, the breaker in the Debug context executes the free operation to release the blockage and allow the thread to continue execution.

[0087] Step S5-3: After the breaker executes the free operation to release the blockage, the server synchronizes the changeGlobalsData in the Debug context to the global variables of the code execution;

[0088] Step S5-4: The Debug interceptor checks whether the gotoStep in the Debug context is set in the code, and if gotoStep is set, jumps to the step where the gotoStep is set to continue execution;

[0089] Step S5-5: The server sends real-time debugging information to the Web client through the messageChannel in the Debug context.

[0090] Among them, the process of the Debug interceptor in step S5-4 checking whether the gotoStep in the Debug context is set in the code includes: first initializing the step stack, putting all steps into the initialized stack, and then popping the step at the top of the stack, checking whether the top step is the gotoStep step, and if it is not the gotoStep step, continue to pop the steps at the top of the stack until it is the gotoStep step.

[0091] Step S6: The Web client receives the real-time debugging information, and renders the currently executed steps and refreshes the global variables according to the debugging information.

[0092] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art can still modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein by equivalents. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A machine learning-based RPA task execution retry optimization method, characterized by: The optimization method comprises: Step S1: collecting debugging records of each successful code debugging in the system, wherein each debugging record includes the code set as sample data and the code step corresponding to the breakpoint set as target data; The sample data is composed of four basic structures, which are variables and data types, operators, control structures, and functions; Step S2: the system analyzes the debugging record and constructs a breakpoint recommendation table; Step S3: The system's Web client establishes a connection with the server; Step S4: the Web client executes the start debugging operation, the system queries the breakpoint recommendation table to automatically set the breakpoint, and transmits the breakpoint data to the server; Step S5: After receiving the breakpoint data, the server debugs the code according to the breakpoint data and transmits the real-time debugging information to the Web client; Step S6: The Web client receives the real-time debugging information, and renders the currently executed steps and refreshes the global variables according to the debugging information.

2. According to the method for optimizing RPA task execution retry based on machine learning in claim 1, it is characterized by: In step S2, the process of constructing the breakpoint recommendation table includes: Step S2-1: number the four basic structures, divide the sample data in each debugging record according to the four basic structures and mark them with corresponding numbers, run the sample data to output a number sequence, the number sequence is the execution path of the sample data, and count the execution paths of the sample data in all debugging records to form a set Y = {y1, y2, ..., y n }, where y n Indicates the nth execution path; Step S2-2: Mark the target data in the sample data in each debugging record, and mark the previous step of the target data with a first label a i , label the next step of the target data with a second label b i , forming the coordinate m i =(a i ,b i ), the m i The breakpoint positions of the sample data are counted, and the breakpoint positions of the sample data in all debugging records are counted to form a set M = {m1, m2, ...m n }, where m n Indicates the breakpoint position corresponding to the nth execution path; Step S2-3: According to the execution path Y={y1,y2,...,y n } and breakpoint position M={m1,m2,...m n }, extract all execution paths corresponding to the same breakpoint position, forming a set y = {y1, y2, ...y k }, where set y is a subset of set Y; Step S2-4: Calculate the execution path y σ Under the condition that a breakpoint position m is executed i The probability of being set is calculated according to the formula: in, Among them, P(y σ |m i ) is at the breakpoint position m i Execute path y under the condition σ The probability of being executed, N y is the breakpoint position m i The number of records of the corresponding execution path y in the set Y, N yσ Execute path y σ The number of records in set y; P(m i ) is the m in all breakpoint positions i The probability of being set, N M is the number of records of all breakpoint positions in the set M, N mi is the breakpoint position m i The number of records in the set M; P(y σ ) is y in all execution paths σ The probability of being executed, N Y is the number of records of all execution paths in set Y, N yσ Execute path y σ The number of records in set Y; Step S2-5: Counting the probability of each breakpoint position being set under the same execution path, and using a comparator to screen out the breakpoint position with the highest probability of being set, and using the breakpoint position with the highest probability of being set as the recommended breakpoint position corresponding to the execution path; Step S2-6: statistics are collected for each execution path and the recommended breakpoint position corresponding to each execution path, wherein each execution path and the recommended breakpoint position corresponding to each execution path are arranged in a row, and a breakpoint position recommendation table is constructed.

3. According to the method for optimizing RPA task execution retry based on machine learning in claim 1, it is characterized in that: In step S3, the system's Web client establishes a persistent connection with the server through WebSocket technology, and creates a unique SessionId mark for the persistent connection.

4. According to claim 1, a method for optimizing RPA task execution retry based on machine learning is characterized in that: The operations of the Web client interface in step S4 include starting debugging, viewing and editing global variable values, setting breakpoints, continuing execution, stepping execution, and ending debugging.

5. According to the method for optimizing RPA task execution retry based on machine learning in claim 1, it is characterized in that: The process of the system querying the breakpoint recommendation table and automatically setting the breakpoint in step S4 includes: Step S4-1: The Web client executes a startup debugging operation; Step S4-2: the system recognizes that a debugging operation is started, and traverses the breakpoint recommendation table to search for an execution path that matches the current code; Step S4-3: The Web client executes a breakpoint setting operation, and the system automatically sets a breakpoint for the code according to the recommended breakpoint position corresponding to the execution path in the breakpoint recommendation table; Step S4-4: The Web client transmits the breakpoint data to the server through a long connection.

6. According to claim 1, a method for optimizing RPA task execution retry based on machine learning is characterized in that: In step S5, after the server receives the breakpoint data sent by the Web client, a Debug interceptor is registered in the code execution engine of the server, and the Debug interceptor is used to generate a Debug context and control code debugging according to the Debug context, wherein the Debug context is bound to the Session Id.

7. The RPA task execution retry optimization method based on machine learning according to claim 6 is characterized in that: The Debug context is composed of fields, including breakpoints, stepOver, breaker, messageChannel, changeGlobalsData, and gotoStep; The breakpoints are used to store breakpoint data transmitted by the Web client; Wherein, breakpoints includes fields flowId and stepId. The field flowId is the process id, which is used to store the breakpoint data set in the process. The field stepId is the code step id, which is used to store the breakpoint data set at the code step. The stepOver is a stepping flag, wherein the stepOver includes true and false, the true represents stepping, and the code needs to be executed from the current step to the next step and paused, and the false represents non-stepping, and the code continues to execute from the current step without pausing; The breaker is a blocking controller, wherein the breaker includes a task operation and a free operation, wherein the task operation is used to block the execution of a thread, and the free operation is used to release the blockage so that the thread can continue to execute; The messageChannel is a message channel used to transmit real-time debugging information to the Web client; The changeGlobalsData is the global variable change data; The gotoStep is a jump step.

8. According to claim 6, a method for optimizing RPA task execution retry based on machine learning is characterized in that: The process of controlling code debugging according to the Debug context includes: Step S5-1: The server creates a new thread to execute the code, and the Debug interceptor starts to take effect, and the Debug interceptor starts to execute before each step of the code is executed; Step S5-2: The server inputs each step of the code into the Debug interceptor. When the Web client performs a step-by-step execution operation, stepOver in the Debug context becomes true, or when the breakpoint data contained in the breakpoints field in the Debug context includes the currently executed step, the breaker in the Debug context executes the task operation to block the thread execution. When the Web client performs a continue execution operation, the breaker in the Debug context executes the free operation to release the blockage and allow the thread to continue execution. Step S5-3: After the breaker executes the free operation to release the blockage, the server synchronizes the changeGlobalsData in the Debug context to the global variables of the code execution; Step S5-4: The Debug interceptor checks whether the gotoStep in the Debug context is set in the code, and if gotoStep is set, jumps to the step where the gotoStep is set to continue execution; Step S5-5: The server sends real-time debugging information to the Web client through the messageChannel in the Debug context.

9. The RPA task execution retry optimization method based on machine learning according to claim 8 is characterized in that: The process of the Debug interceptor in step S5-4 checking whether the gotoStep in the Debug context is set in the code includes: first initializing the step stack, putting all steps into the initialized stack, then popping the step at the top of the stack, checking whether the top step is the gotoStep step, and if it is not the gotoStep step, continuing to pop the steps at the top of the stack until it is the gotoStep step.

Images