This change ensures that workflow context (if a context ID is present) is always loaded before executing a workflow. This needs to happen regardless of the configured fidelity.
Fixes#1490
* Add support for custom journal data logging
* Update ForEach with journal logging
* Update ReadLine with Journal logging
* Update For.cs
* Update While.cs
* Update Switch activity
* Update Join.cs
* Update Timer activities
* Update Azure Service Bus and Telnyx activities
* Update various other activities
* Publish/Subscribe events added to WorkflowSettings and WorkflowRegistry
* Workflow Registry re-indexed and cache refreshed on workflow disable/enable
* IsDisabled property added to WorkflowBlueprintSummary to display disabled status in the UI
* MySql, PostgreSql and SqlServer persistence added to Workflow Settings
* Validation for disabled workflow in Workflow Resumer
* WorkflowSettings configuration added to the appsettings.json
* Workflow Settings added to Elsa.Server.Host startup collection
* IWorkflowSettingsProvider implemented
* Update README.md
* Elsa-Workflow-Settings and Elsa-Webhooks separate modules added and decoupled from Elsa Web
* Delete unused Client projects
* LoadWorkflowSettingsDisabledHandler changes
* FeatureProvider removed, Webhooks plugin merged to Webhooks Feature Plugin
* Update Webhooks and Settings plugin
Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com>
fixes an issue where correlated workflows of different definitions could not signal one another if the signal matches a workflow instance but was not listening for that signal. All startable workflows should always be considered except for the workflow definition that has an already correlated workflow instance matching the correlation ID.
When a parent workflow triggers another workflow using signaling and using the same correlation ID, the distributed lock provider would try to acquire a lock on the same resource, causing a deadlock situation.
This isn't the final fix.
This solves an issue when a workflow uses a fork activity where multiple branches get scheduled, but one of them contains a blocking activity, putting the workflow in the Suspended state. But as the other scheduled activities execute and "unwind" when the leaf node finished, their current scope weren't being re-scheduled.
This particularly fixes the issue where a composite activity can potentially specify its own activity ID, which would break the workflow since the activity definition ID (as generated by the designer) would be different.
