-
Notifications
You must be signed in to change notification settings - Fork 291
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
fx.Options and fx.Module behave differently #918
Comments
In the use-case I'm working on, I want to write app := fx.New(
someModule,
anotherModule,
fx.Invoke(func(lc fx.Lifecycle) {
lc.Append(fx.Hook{OnStart: ...})
}),
) and know that, because it's the last invocation, that fx.Hook is the last thing started in the lifecycle. As it is, everything in the modules is starting after my top-level hook. |
This refactors the command-running utilities to take the fx.Options as variadic arguments, so that fxapps.OneShot can add its own fx.Option. It uses a bit of reflection to convince Fx to gather the arguments to a function without actually calling that function immediately, allowing the oneShot function to run after `app.Start` has finished, when we're sure that all components have started. This works around the startup ordering bug in uber-go/fx#918.
This is a valid issue, thanks for reporting this. Tracking internal issue: GO-1591. |
BTW, just to clarify what the issue is - the issue isn't that fx.Options and fx.Module behaves differently. They do behave differently because they're meant for doing different things :) There are two issues that this issue is tracking:
|
Currently, fx.Module's invokes are run after all the invokes provided at the parent level are invoked. This makes it difficult for module consumers to control the precise invoke orders. This changes the invoke order to run all the invokes in the child module before running any of the invokes in the parent module, and clarify that order in the documentation for Invoke. Solves uber-go#918. Refs GO-1591.
Currently, fx.Module's invokes are run after all the invokes provided at the parent level are invoked. This makes it difficult for module consumers to control the precise invoke orders. This changes the invoke order to run all the invokes in the child module before running any of the invokes in the parent module, and clarify that order in the documentation for Invoke. Solves uber-go#918. Refs GO-1591.
* Fix Invoke order when fx.Module is used Currently, fx.Module's invokes are run after all the invokes provided at the parent level are invoked. This makes it difficult for module consumers to control the precise invoke orders. This changes the invoke order to run all the invokes in the child module before running any of the invokes in the parent module, and clarify that order in the documentation for Invoke. Solves #918. Refs GO-1591. * fix indentation in code sample
Fixed with #925. |
* Fix Invoke order when fx.Module is used Currently, fx.Module's invokes are run after all the invokes provided at the parent level are invoked. This makes it difficult for module consumers to control the precise invoke orders. This changes the invoke order to run all the invokes in the child module before running any of the invokes in the parent module, and clarify that order in the documentation for Invoke. Solves uber-go#918. Refs GO-1591. * fix indentation in code sample
Describe the bug
It appears that
fx.Invoke
's that are in anfx.Module
do not run until after allfx.Invoke
's outside the module.This is not documented in
fx.Module
, andfx.Invoke
's docs sayemphasis on in order :)
To Reproduce
https://go.dev/play/p/SP93TiMiji9
)
Actual behavior
Expected behavior
Additional context
Changing
fx.Module
tofx.Options
(and removing the "mod") makes this behave as expected.The text was updated successfully, but these errors were encountered: