SemianiakaVY/elsa-core
1
0
Fork 0
Code Issues Pull requests Actions 1 Packages Projects Releases Wiki Activity

Commits workflow state during alteration (#6736)

Browse source 
* Reduce default logging verbosity in appsettings.json

* Commit workflow state during alteration execution

Added `ICommitStateHandler` dependency and implemented workflow state commitment in `DefaultAlterationRunner` to ensure state persistence during alteration execution.
This commit is contained in:
Sipke Schoorstra 2025-06-13 08:30:02 +02:00 committed by GitHub
parent 6eccb3540a
commit 935d6987d5
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 9 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
src/apps/Elsa.Server.Web/appsettings.json
View file

@ -1,10 +1,8 @@
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.Hosting.Lifetime": "Information",
"Elsa": "Warning",
"Elsa.Workflows.Runtime.Middleware.Workflows.WorkflowHeartbeatMiddleware": "Warning"
"Default": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"HostBuilder": {

7
src/modules/Elsa.Alterations/Services/DefaultAlterationRunner.cs
View file

@ -4,6 +4,7 @@ using Elsa.Alterations.Core.Results;
using Elsa.Alterations.Middleware.Workflows;
using Elsa.Common;
using Elsa.Workflows;
using Elsa.Workflows.CommitStates;
using Elsa.Workflows.Management;
using Elsa.Workflows.Pipelines.WorkflowExecution;
using Elsa.Workflows.Runtime;
@ -17,6 +18,7 @@ public class DefaultAlterationRunner(
IWorkflowExecutionPipeline workflowExecutionPipeline,
IWorkflowDefinitionService workflowDefinitionService,
IWorkflowStateExtractor workflowStateExtractor,
ICommitStateHandler commitStateHandler,
ISystemClock systemClock,
IServiceProvider serviceProvider)
: IAlterationRunner
@ -81,8 +83,13 @@ public class DefaultAlterationRunner(
// Extract workflow state.
workflowState = workflowStateExtractor.Extract(workflowExecutionContext);
// Commit workflow state.
await commitStateHandler.CommitAsync(workflowExecutionContext, workflowState, cancellationToken);
// Apply updated workflow state.
// TODO: Importing back into the workflow runtime makes sense, but this also causes another SAVE ction of the workflow instance in the DB, which also happens in the previous step during the commit action.
// Can we avoid this? Perhaps we need more granular control over when we purge and when we save to DB.
await workflowClient.ImportStateAsync(workflowState, cancellationToken);
// Check if the workflow has scheduled work.