New options to control retry logic for transient failures #4750
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
|
I was hoping that maybe we could expose the configuration lambda to the calling code so that we can not only change the retry count, but also e.g. the time between retry attempts, and perhaps even add additional strategies if the user wants to? |
|
@sfmskywalker I have introduced "Func<int, TimeSpan> SleepDurationProvider" option. I think the RetryCount and SleepDurationProvider should be enough. |
NightWuYo
changed the title
sfmskywalker
approved these changes
Jan 6, 2024
sfmskywalker
pushed a commit
that referenced
this pull request
Jan 6, 2024
* Add an option to control the number of automatic retries for transient failures. * Add SleepDurationProvider option for ElsaClientBuilderOptions --------- Co-authored-by: admin <admin@admin.com>
sfmskywalker
added a commit
that referenced
this pull request
Jan 6, 2024
* Update packages.yml for version 3.0.1 The packages.yml workflow file has been updated to target the v3.0.1 branch instead of main. The version also has been updated from 3.0.0 to 3.0.1 in the version prediction logic. Hotfix tags usage has been removed. * Update git branch for commit verification in workflow The Github workflow's step for verifying commits' existence has been updated. Instead of searching in the 'origin/main' branch, the workflow now checks in the 'origin/v3.0.1' branch. This modification ensures compatibility and consistency with the version being used. * Update Elsa.Studio package versions The Elsa.Studio and Elsa.Studio.Login.BlazorWasm packages in the Elsa.ServerAndStudio.Web and Elsa.Studio.Web projects have been updated from version 3.0.0-preview.177 to the stable version 3.0.0. This is to ensure we're using the stable and reliable versions of these packages in our projects. * Add background execution to activities and update HTTP requests Significantly enhanced the capabilities of background execution of activities. Included a change in activity type of "SendHttpRequest" from 'Task' to 'Action'. Introduced new classes for handling outcomes of context in background execution. Made some necessary adjustments to HTTP Request Task to handle sending HTTP requests from a background task. Updated several middleware classes to align with these modifications. * Add background execution handling to activity context This commit adds the ability to manage the background execution state directly within the activity execution context. This includes adding methods to set and verify the background execution state, and modifying the existing code to use these new methods. A method for handling activity scheduling during background execution has also been started, but its implementation is not finished yet. The HTTP Request activities were updated accordingly to reflect these changes. * Add scheduling function for background activities This commit achieves two main goals. Firstly, it introduces two new classes called ScheduledActivity and ScheduledActivityOptions to store scheduled activities' information. Secondly, it modifies how activities are executed in the background by capturing the scheduling information as a serializable format and storing it in the workflow execution context properties dictionary. This change allows the workflow execution context to resume the activity execution context. * Refactor HTTP request handling by removing SendHttpRequestTask SendHttpRequestTask was deleted and its functionality was merged into SendHttpRequestBase. This consolidation led to the addition of StatusCode and ResponseHeaders output fields in SendHttpRequestBase. Another change includes the update in FlowSendHttpRequest to indicate that it's no longer deprecated. Also, HttpHeaders class was extended to accommodate HttpResponseHeaders objects. The consolidation was done to streamline the HTTP request handling process. * Update GitHub Actions workflow for new release The GitHub Actions workflow configuration has been updated to target the '3.0.1' branch instead of 'main'. Furthermore, the preview version set in the workflow has been updated to '3.0.1-preview', changing from the previous '3.0.0-preview'. * Update branch verification in GitHub workflow The GitHub workflow configuration has been updated to verify that the commit exists in the branch 'origin/3.0.1' instead of 'origin/main'. This is done during the automated package generation process. * New options to control retry logic for transient failures (#4750) * Add an option to control the number of automatic retries for transient failures. * Add SleepDurationProvider option for ElsaClientBuilderOptions --------- Co-authored-by: admin <admin@admin.com> * Add IExecuteWorkflowApi interface and refine retry policy configuration A new interface, IExecuteWorkflowApi, was created to handle execution and dispatch of workflow definitions. This breaks down functionalities previously present in IWorkflowDefinitionsApi. Also, the retry policy configuration for HTTP requests has been refactored. Instead of hardcoding retry settings, now a delegate method can be optionally passed to customize the behavior. This makes it more flexible and shifts the responsibility of configuring retry policies to the client. * Add option for synchronous broadcast in WorkflowInbox This update introduces a new option to control synchronicity when broadcasting messages in the WorkflowInbox. The 'BroadcastWorkflowInboxMessageOptions' class allows the developer to specify whether the broadcasting will occur synchronously or asynchronously. The update also includes a new Endpoint and Workflow for demonstration and testing of this functionality. * Update FastEndpoints packages to version 5.21.2 The current commit updates the version of all FastEndpoints packages from 5.20.1.7-beta to 5.21.2 in the 'Elsa.Api.Common' project. This ensures we are using the most recent stable release of these packages. #4747 * Add decimal check in PolymorphicObjectConverter In the PolymorphicObjectConverter class, the check for primitive types and specific object types was updated to include decimal. Fixes #4714 * Refactor Dapper workflow and update migrations Modified the store service to optimize the SaveManyAsync method by converting input to list only once. Also, enhanced deletion query in the store service to enable usage of different primary keys. Made changes in the Dapper migrations, replacing "NodeId" with "ActivityNodeId". * Update workflow to use main branch and version 3.1.0 The workflow has been updated to work with updates on the 'main' branch rather than the 'v3.0.1' branch. Also, the version number for the 'VERSION' variable in preview mode has been updated to 3.1.0 from 3.0.1. * Remove unnecessary Elsa Server activities Deleted sample files: DataSourceActivity, MyEndpoint, and MyEventWorkflow from the Elsa Server Web bundle as part of our ongoing codebase optimization strategy. These files were no longer required and their removal simplifies our code structure. * Update package workflow to reference v3.0.1 The GitHub actions workflow has been updated to pull from branch v3.0.1 instead of main. This change affects the commit verification and version setting steps, now using version 3.0.1-preview in the workflow process. * Update Elsa.Studio packages to version 3.0.1-preview.196 This commit involves updating the versions of `Elsa.Studio`, `Elsa.Studio.Core.BlazorWasm`, and `Elsa.Studio.Login.BlazorWasm` packages in `Elsa.ServerAndStudio.Web.csproj` and `ElsaStudioWebAssembly.csproj` files to 3.0.1-preview.196. This update will incorporate the new changes and improvements included in this newer version. * Update Elsa.Studio package versions The Elsa.Studio and Elsa.Studio.Login.BlazorWasm package versions have been updated in the Elsa.Studio.Web project. Both package versions have been upgraded from 3.0.0 to 3.0.1-preview.196. * Remove unused Workflow models and simplify AddStorageDriver method The commit removes BackgroundExecutionOutcome and BackgroundExecutionResult models from Elsa.Workflows.Core, as they are no longer in use. Additionally, it simplifies the AddStorageDriver extension method in ModuleExtensions.cs, now it directly adds the service as an implementation of the IStorageDriver interface. * Remove unnecessary dependencies in DefaultBackgroundActivityInvoker Dependencies on IBookmarksPersister and IWorkflowStateExtractor have been removed in the DefaultBackgroundActivityInvoker.cs file. Additionally, an unused `using` statement for Elsa.Workflows.Helpers has been eliminated. This commit aims to declutter the code and increase its maintainability by eliminating unnecessary dependencies. --------- Co-authored-by: Night Wu <lofrank@outlook.com> Co-authored-by: admin <admin@admin.com>
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.
Add a new option to control the number of automatic retries for transient failures.
Currently when a workflow is triggered from Elsa Studio, it will retry for 3 times automatically if failed, and each time it will start from the the beginning. This means some activities may be run for up to 4 times (for example, when the workflow has two activities, and the first one activity always gets success and the second one is always failed, the first one will be run for 4 times successfully).
Fixes elsa-workflows/elsa-studio#108