Add constructor runtime to fxevent.Run events #1213
Labels
Comments
tchung1118
added a commit
to uber-go/dig
that referenced
this issue
Jul 2, 2024
This change adds runtime of the associated constructor
or decorator to dig.CallbackInfo.
For example, users can access the runtime of a particular
constructor by:
```go
c := dig.New()
c.Provide(NewFoo, dig.WithProviderCallback(func(ci dig.CallbackInfo) {
if ci.Error == nil {
fmt.Printf("constructor %q finished running in %v", ci.Name, ci.Runtime)
}
}))
```
This change is a prerequisite for adding uber-go/fx#1213
to report runtime of constructors in Run events.
tchung1118
added a commit
that referenced
this issue
Oct 9, 2024
This PR adds runtime info of constructors and decorators to Run events, and the runtime of every constructor and decorator (including ones created by fx.Supply and fx.Replace) will be logged when logging Run events. This will help us identify which part of the dependency graph takes long to construct. Closes #1213
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Recently I had to investigate a service not starting up properly due to dependency construction taking a long time in certain zone. While we log fxevent.Run events when a constructor runs and returns results and/or error, it lacks the information on how long a certain constructor took to run, which barred us from being able to further investigate and find out which part of the DI graph could be slowing down and come up with some hypotheses on what could be going on in that zone.
Describe the solution you'd like
I propose that we include the runtime of each constructor in fxevent.Run events.
Describe alternatives you've considered
Collecting cpu profiles at application start-up, including provides, runs, invokes, and OnStart hooks, would also have enabled us to identify which constructors are running slower than others. However, in this particular situation, the docker container that's starting the service up was being terminated in the middle of DI graph construction, so optionally emitting CPU profiles at start-up wouldn't have helped us.
Is this a breaking change?
This is just adding more information to an fxevent. I don't think this is a breaking change.
The text was updated successfully, but these errors were encountered: