Refactor step execution logic #46
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- refactored all the prep work into the handleNewServiceRequestEvent method - remove iterative loop to execute all steps continuation of step will be handled in another event handler
Ziyang-98
approved these changes
Jan 31, 2024
|
Also, can I check if how to see the current step is running and the progress status of the current step for the service in the FE? This is to show the status of the pipeline in the dashboard |
@Ziyang-98 not completely. For example, the API Step currently only makes a simple GET request to a dummy endpoint
We will expose an endpoint for the frontend to query step statuses as well as service request statuses |
joshtyf
deleted the
refactor/apply-granular-control-over-step-execution
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
In this PR, I split the execution of the service request.
Rationale
Previously, we were executing the steps within an iterative loop. However, we had no control over the execution flow once it started as it was hidden within the function. This poses a challenge to the future
Approvestep that we want to implement.Change
This PR creates a new event called
StepCompletedEvent. With this new event, we can trigger it whenever a step finishes completion. The handler for this event will prepare the subsequent step according to the results/errors of the completed step.This way we can introduce a pause within the execution flow. For example, we can create an
Approvalstep that sends a notification to the approver. But thisApprovalstep should not trigger theStepCompletedEvent. The event is only triggered when the backend server receives an API request from the frontend that signals the approval.For other steps like the
APIStepcreated in #38, we can trigger theStepCompletedEventat the end of execution without any worries.