The order here is important. Before this change, the flowchart would determine that there was still pending work, after which the FlowJoin would then cancel that work, leaving the Flowchart uncompleted.
In the scenario where this resolver is used, it's not about discovering ports, but about constructing a graph from the workflow by going through each activity or activities property.
* Remove unused NOOP stores
* Add activity execution manager and FindAsync method to store
The notification is used to broadcast changes to SignalR clients.
* Refactor ActiveActivityExectionContexts
Instead, the workflow state extractor is in control of what gets extracted.
* Add missing files for activity execution deleted broadcast
* Update Flowchart to not fault when child faults
* Update Flowchart to support scheduling existing activity instances
* Update namespaces from Services to Stores
* Improve activity cancellation alteration
* Update ScheduleActivity alteration
* Implement Alteration types and engine
* Implement Alteration APIs
* Refactor activity work item with support for activity input
* Serialize scheduled activities as part of workflow state
* Add signal to schedule child activity
* Implement stores for plans and jobs
* Add EF Core provider
* Add Retry endpoint
* Keep root context as always active. The root context is the workflow execution context and contains persistent variable state
* Regenerate EF Core migrations
* Handle orphaned activity execution contexts
* Refactor workflow execution factory
* Enable configuring Jint from Program
* Update ModifyVariable alteration with support for type deserialization
* Use ShortGuid for identity
* Cleanup WorkflowServer host
* Fix flowchart next activity scheduling bug
This fixes a bug where the Flowchart activity would schedule connected activities regardless of the outcome of the completed activity.
* Cancel activity execution when cancellation token is triggered.
* Enable user to handle HTTP endpoint validation failures as outcomes
* Don't respond with full details in case of HTTP Endpoint faults for security
* Implement Incident Strategy interface and resolver
* Add ActivityIncident model
* Add IncidentCount and Incidents properties and update migrations
* Expose incident strategies API endpoint
* Update API client with Incident Strategy models
* Replace Fault with Incidents
* Register fault status when any children have faulted
* Map incident count
* Remove unnecessary AlreadyCompleted result
* Ensure next activities are scheduled only if activity completed normally
* Incident roundtrip and fix workflow instance realtime updates
* Remove unused variable
* Add integration tests
* Refactor Telnyx activities to use instance ID for correlating events
* Ensure SetVariable sets value in correct scope
* Fix race condition between new instances that are being resumed
* Fix tests
* Use NoTracking for EF Core
* Use Activity ID as Node ID for modern tooling
* Fix DispatchWorkflow activity
* Update tests and remove redundant ToolVersion
With this change, the user has better control over what activity to use as the starting node. Originally, the designer wouls store the ID of the first activity to have dropped on the designer, which would cause unexpected results when later adding another activity as the root node. The logic is now changed to:
1. Use the trigger node if that node was triggered.
2. Use the Start node, if there is one.
3. Use the first activity that has no inbound connections.
4. Use the first activity in the collection.
* Fixes the issue with httpendoint not being suspended #4143
* Simplify HttpEndpoint and bookmark processor
* Fix issue with null workflow state ID
* Remove implicit instalment of EF Core provider for Trigger and Bookmark store
---------
Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com>
