-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds ability to unregister workflows #650
base: master
Are you sure you want to change the base?
Conversation
|
// In case a string is passed, that should be the alias of the workflow. | ||
// In case a function is passed, all the aliases referring to the workflow (if any) will be unregistered as well. | ||
// This method calls panic if workflowFunc doesn't comply with the expected format. | ||
func UnRegisterWorkflow(wf interface{}) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. So unregistering is not really what you want. You want ability to register workflows not globally, but to a specific Worker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe #563 is what you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
- Register the child workflow (mandatory)
- 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that mocks are linked to a specific instance of a TestWorkflowEnvironment and are not related to registrations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
No description provided.