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.
Having "pending" outcomes isn't practical - it would require the user to always connect them to the activity itself if they did not want to continue the workflow.
* Side panel initial draft.
* Added latest version to the side panel. Made it a slide panel.
* Added side panel component to registry. Fixed display issue on instance viewer side panel.
* Auto genearted readme files.
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.
* defined open, close and navigate activities
* sample created
* inherit DriverId
* ClickElement added
* implemented TypeText activity and NavigateToW3School sample
* OpenBrowser headless mode
* RPA: GetText added
* fix readme
* try/catch pattern in base class. Thanks to sfmskywalker for the tip
* Update components.d.ts
Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com>
