From the documentation, it’s not immediately clear what can be a DI Scope of Activity/Workflow Implementation/Stub. What can be a singleton and what should be created for each invocation of the workflow?
Activity implementations are Singletons, stateless, and reused across workflows and worker threads.
Should each instance of a workflow implementation create or use its own set of activity stubs?
Is it a correct implementation to create an activity stub separately as a singleton and inject it into each instance of a workflow implementation?
Or should one activity stub be used only in one workflow implementation instance?
Can we have only one instance of Workflow implementation and return it every time inside the factory passed to addWorkflowImplementationFactory? If this Workflow implementation is stateless (doesn’t store anything in the instance fields) and thread-safe.
Can we have only one instance of Workflow stub if we don’t need to pass different options and use it for triggering the workflow from parallel executors? I think that probably no and one workflow stub - one workflow id (because we can pass workflowId as a parameter when we create a stub), but let’s make this question complete.
These questions probably boil down to questions if Activity/Workflow stub/implementation has a state and if it’s thread-safe. But it also could be influenced by the semantic of our abstractions.
This question rises when we use dependency injection to initialize activities and workflows.