Closed JacobOaks closed 2 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 98.73%. Comparing base (
9814dd3
) to head (4626474
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Did we validate this in internal CI? I don't see a reason it should affect anything but in case.
Yes, this has been validated in internal CI @sywhang
@JacobOaks do you want to cut a release?
Consider the following example:
The relevant issue to surface to the user is that they are double providing the same type. However, the actual error message is:
Which contains an additional error related to how the custom logger could not be built.
This is because Fx will try to continue to build the custom logger in the face of DI failure, theoretically to report issues through the right channels. But after an error occurs when providing anything, Fx refuses to provide any more types - leading to a subsequent error when trying to build this custom logger that depends on the
fx.Lifecycle
type.This is a common issue that can be misleading for new engineers debugging their fx apps.
I couldn't find any particular reason why user-provided provides are registered before these Fx types, so this PR switches this ordering so that custom loggers can still be built if they rely on the Fx types, which cleans up the error message: