Describe the bug
The example provided here does not seem to work as expected. If PORT is not defined it correctly prints
=== RUN TestExample
$PORT is not set
--- PASS: TestExample (0.00s)
PASS
However if PORT is defined it fails
Failed: must provide constructor function, got &{127.0.0.1:8080 <nil> false <nil> 0s 0s 0s 0s 0 map[] <nil> <nil> <nil> <nil> {{} 0} {{} 0} {{{} 0} {0 0}} <nil> {0 0} map[] map[] [] {{} {{} {} 0} 0}} (type *http.Server)
To Reproduce
Drop the example in a go unit test and add t.SetEnv("PORT", 8080)
Expected behavior
I guess the call to fx.Provide must be replaced with
return fx.Provide(
func() *http.Server {
return &http.Server{Addr: fmt.Sprintf("127.0.0.1:%s", port)}
}
)
which actually reaches fx.Invoke ListenAndServe
Additional context
Stumbled accross this because I'm trying to figure out a good way to handle errors when reading configuration (from env variables but that could be in a file as well). Generally speaking, is it a good idea to delay error handling in that case? I understand that this fx.Error allows to delay config read error after the call to fx.New thus maybe allows to execute cleanup code if needed.
edit: regarding that Provide error, would this make any sense to have a hook that triggers on Provide errors (e.g. before app.Start here)
Describe the bug
The example provided here does not seem to work as expected. If PORT is not defined it correctly prints
However if PORT is defined it fails
To Reproduce
Drop the example in a go unit test and add
t.SetEnv("PORT", 8080)Expected behavior
I guess the call to fx.Provide must be replaced with
which actually reaches
fx.Invoke ListenAndServeAdditional context
Stumbled accross this because I'm trying to figure out a good way to handle errors when reading configuration (from env variables but that could be in a file as well). Generally speaking, is it a good idea to delay error handling in that case? I understand that this
fx.Errorallows to delay config read error after the call tofx.Newthus maybe allows to execute cleanup code if needed.edit: regarding that Provide error, would this make any sense to have a hook that triggers on Provide errors (e.g. before app.Start here)