Adds ability to unregister workflows

[algobardo]

No description provided.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[mfateev]

Would you add comment in which situation this function is needed. Otherwise it creates false impression that it should be called on shutdown. My understanding that it is needed only for test scenarios, correct?

[algobardo]

Hi Maxim,
you are right, this function is only for testing. If you have a better idea on how to expose this functionality I can move it around, otherwise I will just add a comment.
Please note that it would be nice if cadencefx unregisters all workflows OnStop, see T2502463

[mfateev]

I see. So unregistering is not really what you want. You want ability to register workflows not globally, but to a specific Worker.

[mfateev]

I believe #563 is what you want.

[algobardo]

I think #563 is more than I want. There are two problems that I want to solve, and this diff is only the first step to solve them, possibly the wrong one.

• Whenever there are two tests in the same package that attempt to do fxtest.New(Module).Start() only the first can succeed, since the second one will fail to start due to the attempt to register the same workflows twice. The same also applies for activities registration. Cadencefx should unregister all workflows and activities OnStop. (This is T2502463)

• When testing a workflow that calls a child workflow we need to:

1. Register the child workflow (mandatory)
2. Mock it with OnWorkflow (optional)
   In the case we only want to do 1. and run the actual workflow, the child workflow will necessarily use a mock of its downstream dependencies. The ability to unregister and re-register workflows should enable us to register the same workflow with different mocks of its dependencies in different tests.
   The same applies for activities as well.

[mfateev]

I thought that mocks are linked to a specific instance of a TestWorkflowEnvironment and are not related to registrations.

[algobardo]

We don't register workflows nor activities in init(), and I don't fully understand how that is supposed to work within an fx service. Our workflows and our activities are methods of types that are "provided" (read instantiated) by fx https://github.com/uber-go/fx/blob/master/app.go#L89, and as such they are not available at init time. Such types have their own dependencies that are other types instantiated by fx.

[algobardo]

Note that #563 also mentions the same pattern:

func New(repositories, gateways, etc) activity { .  <---- fx constructor and dependencies
    act := &activity{...}
    // do I activity.Register(act.run) here?  <------  registration not in init

[mfateev]

I see. You kind of fight against the original Cadence design that workflows and activities are functions, not methods.
The original design was that fx service instantiates a background activity context which activity uses to get all the external dependencies from. And registration is global as all it does is to map a function name to a specific function implementation. And it is overridable through a TestWorkflowEnvironment for unit testing.

[mfateev]

I agree that some users are OK calling activities by string name instead of function pointer and want to use method pointers to register them. But until #563 is implemented I would recommend to stick to the supported way of using background context to pass dependencies to activities.