Because we create service before the yarpc.Dispatcher it is hard for clients to get it in the constructor, they have to get it during request serving to e.g. create client.

With this change services will be able to resolve Dispatcher at construction time.

fx.OnStart reduces boilerplate when adding a function to be run when the application is started.

It reduces boilerplate like:

fx.Invoke(
    func(lc fx.Lifecycle, a *Type1, b *Type2) {
        lc.Append(fx.Hook{
            OnStart: func(ctx context.Context) error {
                doSomething(a, b)
            },
        })
    },
)

into

fx.OnStart(
    func(a *Type1, b *Type2) {
        doSomething(a, b)
    },
)

This is a WIP implementation which implements the logic "outside" of fx, to start a discussion of whether this is what we want.

There are some details to consider:

• What happens if the graph has a context and the passed in function has a context Currently: If the first argument is a context, it's always the Start context. Any other argument as context is provided from the graph.
• What is the source of the OnStart for errors? Today it'll be a generated function, but fx should probably skip these. We might want a t.Helper() to provide fx helpers that don't pollute the stack.

This could also be implemented "internally" in fx, which would complicate the core framework but possibly provide better stacks/errors.

See T2133659 for more details.

Several things still to tidy up, but seems to be working to review.

README.md is a good place to start and examples/dig/* to see how one might use it in a "real" application.

TODO list:

• [x] Thread safety
• [x] Rebrand Inject to Register

Other TODOs are now filed as issues.

#282 #283 #284 #285

Given a stack var Stack = fx.Options(A.Module, B.Module, C.Module)

What options are available to the user to either mutate or provide a custom A.Module. Right now the only option is to copy-pasta the stack (and therefore forego and branch the tight default version).

I'd like to think through being able to override one of the options, or ability to decorate the object right after it's creation before it's piped through the rest of the graph.

Option A: Do nothing

Declare this as SOL situation and have the service owner re-assemble the stack from the components.

This has two downsides that jump out:

• Versioning control has been transferred from the stack to the service. This can be solved by still importing the stack in the glide.yaml and picking up the right version
• More importantly: additional default components that get added to the stack are no longer picked up, meaning every now and again the service author would have to manually peek to see what's going on in the stack and sync the changes.

Option B: Override approach

It could look something like:

import "default/stack"
import "fx"

func main() {
  // MyA.Module and A.Module provide the same types
  fx.New(stack.Stack, MyA.Module).Run() 
}

And would require Fx to understand which option is providing which types.

Option C: Decoration

This could be a new option that functions very similar to Invoke, however to solve the siblings problem it gets executed first before the rest of the constructors.

import "default/stack"
import "fx"

func main() {
  // <- A.Type is what's provided by A.Module
  fx.New(stack.Stack, fx.Decorate(func(a A.Type) { 
    a.mutate = true // ...
  }.Run()

I was working on writing a new Module for another project that also uses zap, and I noticed that FX currently uses zap on master, which is way behind the latest zap development on dev. I think this was on purpose (ie I think the whole purpose of the master branch on zap is so that FX could develop against a stable zap API), but as you approach 1.0 for FX, I think getting the latest updates would be a really good idea, so that users of FX are using zap as it will be going forward.

This also does a global glide update, but I think this is the only breaking change. It would be a good idea to audit the rest of the dependencies for updates before FX goes to 1.0 as well. If this is merged, it would be nice to just merge zap dev into master, and then have this depend on master again.

A few notes:

• This is a half hack job. I am just learning the workings of FX, and this should be a drop-in replacement, but I worked to get this just passing tests. This could use a fine-tooth comb by one of the FX maintainers, and I left some TODOs in the code as it is now.
• I think LogBuilder could use some general work afterwards, but I know you're all pushing for 1.0 so this is for later.
• Instead of using LogConfiguration, it might be nice to directly use zap's new configuration struct.
• A general wish: I wish FX wasn't so tightly tied to zap, I wish we could have other logging libraries as well (and a lot of users will want this). It would be non-trivial but not too difficult to separate the tight coupling to zap.
• This PR was a pain in the butt, and if you want to merge it, we should go over it NOW and get it in before this gets into rebase world. I'm happy to do a video chat to get this done quickly, or if someone else wants to take it over, go for it.

@sectioneight @akshayjshah @glibsm @anuptalwalkar

Adds sentry integration for ulog.

Can be configured out-of-the-box with defaults by just providing a logging.sentry.dsn in config, or for those wanting more control there is a way for that too.

For yaml files, it feels more natural to have:

logging:
  text_formatter: true

Instead of:

logging:
  textFormatter: true

With how the config reads yaml files right now, the latter will work, while the former will not, unless you have explicit yaml tags (right?). Could we make this magical to do either/or? I haven't looked into it at all, so it may take a change to the yaml library.

Also something to note that you might want to use: https://github.com/peter-edge/pkg-go/blob/master/yaml/pkgyaml.go#L55

What this allows me to do is to have either yaml or json files, and do the same thing. This also makes parsing work if there are only json tags without yaml tags, which gets REALLY useful when you have protobuf/thrift entities like

message Config {
  bool stdout = 1;
}

And you can just have protobuf/thrift generate the structs, which (at least for protobuf) have json tags already, and then read them in using that function.

It's very easy for users to make one of their params types have unexported fields which means it will silently have the default value.

It seems reasonable to me to to say that a struct being used as a dig.In struct should not be used for anything else. This means that we can warn users if any fields are unexported and improve this silent rough edge users can easily hit.

What

Currently, the FX errors if you Provide/Supply for an unnamed/ungrouped type multiple times. However, there are use cases where overriding an existing Provide or Supply becomes useful, like in testing(#649). Also, this becomes useful for big applications with a liberal API allowing their users to override the default setup of modules. That is, the API devs prepare the default set of modules, while a user can swap out a module of their choice through overriding.

Why

Essentially, the feature would allow APIs like:

some.New(Modules, WithModule(custom.Module))

Currently, users have to decouple Modules, understand what needs to drop out, and pass their custom one. With this feature, users would add desired things on top.

How

API

// OverrideSupply overwrites values passed to Supply and constructed with Provide.
// It mimics Supply with one difference - it does not error if there are multiple instances of a type
// are supplied/provided. Instead, OverrideSupply forces the Supply.
// Only one override can happen for a type.
func OverrideSupply(vals ...interface{}) Option

// OverrideProvide mimics Provide with one difference - it does not error if there are multiple instances of a type
// are provided or supplied. Instead, OverrideProvide forces the provide.
// Only one override can happen for a type.
func OverrideProvide(vals ...interface{}) Option

Implementation ideas

• A naive idea would be to collect all the overrides and exclude Provides and Supplies with conflicting types. However, the problem arises when provided ctor returns multiple types, and overriding happens for only one of them, as the whole ctor is excluded. The issue might be ok for some cases and easily detected, thus errored. The good thing is that this can be implemented beneath FX only, without digging into dig. Also, this should be fine enough for testing needs in #649.

• A more thorough approach without the issue of the approach above would go dipper into dig and somehow be part of graph construction. Unfortunately, I am not that familiar with dig implementation to understand the complexity and feasibility, so kindly ask you to help. Ideally, the implementation should still execute a conflicting ctor but exclude an overridden type from the dependency graph.

Happy to submit a patch once there is a decision on how to proceed.

When fx is run with a very short timeout, it's possible for the timeout error message to be in a bad format "OnStart hook added by failed" where the name of the OnStart hook's caller hasn't been recorded before the context times out.

This fixes the error message generation to not rely on the OnStart hook's caller always being known to fix this race.

Fixes #815

When there is a timeout, we try to generate a timeout report by printing what timed out. There is a race in this logic which sometimes results in CI failures like this:

    --- FAIL: TestAppStart/Timeout (0.01s)
9 app_test.go:905: 
10 Error Trace:	app_test.go:905
11 Error:      	"OnStart hook added by  failed: context deadline exceeded" does not contain "OnStart hook added by go.uber.org/fx_test.TestAppStart.func1.1 failed: context deadline exceeded"
12 Test:       	TestAppStart/Timeout
13 FAIL

We can actually repro this pretty easily by changing the timeout in TestAppStart/Timeout to 1 nanosecond:

context.WithTimeout(context.Background(), time.Nanosecond)

fx ➤ make test                                                                                                                                                                                git:master*
--- FAIL: TestAppStart (0.00s)
    --- FAIL: TestAppStart/Timeout (0.00s)
        app_test.go:905:
                Error Trace:    app_test.go:905
                Error:          "OnStart hook added by  failed: context deadline exceeded" does not contain "OnStart hook added by go.uber.org/fx_test.TestAppStart.func1.1 failed: context deadline exceeded"
                Test:           TestAppStart/Timeout

We provide a way to shutdown an app via the Shutdowner interface but, we do not provide a way to specify/change the exit code. This commit adds support for shutting down apps with an exit code. Exit code can be controlled by providing a new Option to configure the Shutdowner. This can be done via shutdowner.Shutdown(WithExitCode(...))

• For apps that use app.Run(), the exit code is read directly and returned.
• For apps that are orchestrated with app.Start() and app.Stop(), a new function app.DoneWithCode() is presented that works similar to app.Done(). The following code illustrats its usage -

app := ...
app.Start(...)
done := app.DoneWithCode()
res := <-done
app.Stop(...)
res.ExitCode // captures the exit code

Refs: GO-981, #763

If this hook is intended to call long-running goroutines like this, then why it waits for an error that never can be provided due to the locking nature of the call?

We only can return nil there, otherwise, if try to return s.ListenAndServe(), then we get the start timeout.

So, does fx assume to omit error handling here?

Hello 👋

I have an service where we have to make a bunch of structs that have really trivial constructors. Namely, all they do is store the parameters wholesale. For example:

type Foo struct {
    MyBar  Bar
    MyBaz  Baz
    MyQuux Quux
}


func NewFoo(mbr Bar, mbz Baz, mq Quux) Foo {
    return Foo{
        MyBar: mbr,
        MyBaz: mbz,
        MyQuux: mq,
    }
}

The Bar, Baz, and Quux are all fx.Provide'd elsewhere. I have a bunch of structs that look like this, that take various combinations of these dependencies.

Is there a standard way of avoiding all this boilerplate?

I did try this:

type FooParams struct {
    fx.In
    Foo
}
type Foo struct {
    MyBar  Bar
    MyBaz  Baz
    MyQuux Quux
}


func NewFoo(fp FooParams) Foo {
    return fp.Foo
}

in the hopes that Fx would not see the Foo member and only see the MyBar, MyBaz, and MyQuux members embedded, but Fx was not tricked and declared that there was a circular dependency.

Shutdowner is a useful mechanism for willfully exiting applications, but it can be even better. To this end, the application channel can be upgraded to carry a value of type

type SignalWithValue struct {
    Signal os.Signal
    ExitValue interface{}
}

The exit value can then be recovered from the App.Done channel value or from App.Run return value.

This is mostly useful to set the application exit code to some value, but in a slightly more generic way than simply returning int.

For a bit of context: Dotnet Core allows applications to set the eventual application exit code without actually exiting. This enables a pattern of the following sort:

System.Environment.ExitCode = 0;
// do things
// bad things happen
System.Environment.ExitCode = 255;
// Perform an orderly shutdown
(IHostApplicationLifetime).StopApplication();

Thus, Dotnet Core can avoid passing any values to StopApplication, but we don't have such a luxury in Go.

All of the information/examples that I can find about how to use Fx in the "correct" way are centered around long-lived processes (HTTP servers and the like). I really like how my application is structured with Fx, but I'm not quite sure how to use it for e.g. a CLI application that should be running for < 1 second.

For instance, is there any way to silence the log output entirely? Is there a way to default to not a long-running process?

Not a major issue, but example_test relies on port 8080 being available, so when 8080 is being used by another process, it fails without much info:

--- FAIL: Example (0.01s)
got:
Executing NewLogger.
Executing NewMux.
Executing NewHandler.
Starting HTTP server.
Stopping HTTP server.
want:
Executing NewLogger.
Executing NewMux.
Executing NewHandler.
Starting HTTP server.
Got a request.
Stopping HTTP server.
{"level":"info","ts":1624405878.099044,"msg":"providing","type":"fx_test.Username","constructor":"go.uber.org/fx_test.ExamplePopulate.func1()"}
{"level":"info","ts":1624405878.099235,"msg":"providing","type":"fx.Lifecycle","constructor":"go.uber.org/fx.New.func1()"}
{"level":"info","ts":1624405878.099299,"msg":"providing","type":"fx.Shutdowner","constructor":"go.uber.org/fx.(*App).shutdowner-fm()"}
{"level":"info","ts":1624405878.099367,"msg":"providing","type":"fx.DotGraph","constructor":"go.uber.org/fx.(*App).dotGraph-fm()"}
{"level":"info","ts":1624405878.0994182,"msg":"invoke","function":"reflect.makeFuncStub()"}
{"level":"info","ts":1624405878.099509,"msg":"running"}
FAIL
FAIL	go.uber.org/fx	1.802s
ok  	go.uber.org/fx/fxtest	(cached)
ok  	go.uber.org/fx/internal/fxlog	(cached)
?   	go.uber.org/fx/internal/fxlog/foovendor	[no test files]
?   	go.uber.org/fx/internal/fxlog/sample.git	[no test files]
ok  	go.uber.org/fx/internal/fxreflect	(cached)
ok  	go.uber.org/fx/internal/lifecycle	(cached)
ok  	go.uber.org/fx/internal/testutil	(cached)
FAIL

We should change the test to check if 8080 is available and pick a different port if it's not available.

The ability to create several dependencies from a single constructor function is very useful, but it makes it very hard to replace a dependency during tests.

func CreateDep() (dep.One, dep.Two, error) {...}

Currently we maintain several dependency trees, one for production/main and others for tests. This is a manual process, where one needs to constantly remember to adjust trees when some dependencies change. I read in previous issues that there were attempts to replace dependencies in tests, but without any real progress on that. That's why I propose to limit the amount of dependencies one can produce from a single constructor. This will make it much easier to "ignore" a constructor function and "replace" it, impacting only 1 dependency. I know this is a breaking change and that's why I propose to include this as part of the major release.