"multiple bindings for *invalid type"

[OscarHanzely]

Describe the bug

I am actually not 100% sure this is a pure bug of mis configuration, but since I googled and asked at some places and was not provided with any suitable answer I believe it is unexpected behavior. Let me explain: once in a while wire complains about the error on type that is for some reason now visible to it. This scenario is particularly weird, because it seems to treat two different types but because wire does not detect the type properly it tricks him to cause unrelated error of double definition in provider set.

This is the error:

/server/config.go:50:15: Configs has multiple bindings for *invalid type
	current:
	<- provider "ProvideLiveMediaHandlerConfig" (/server/config.go:135:6)
	previous:
	<- provider "ProvideLivePostgresConfig" (/server/config.go:130:6)

To Reproduce

The configuration on those lines are these two providers:

// ProvideLivePostgresConfig returns valid postgresSQL config instance
func ProvideLivePostgresConfig(c *Config) *livemediaobject.PostgresSQLConfig {
	return &livemediaobject.PostgresSQLConfig{DatabaseDSN: c.databaseDSN} // line 131
}

// ProvideLiveMediaHandlerConfig additional handler configs
func ProvideLiveMediaHandlerConfig(c *Config) *livemediaobject.HandlerConfig {
	return &livemediaobject.HandlerConfig{Env: c.appEnv} // line 136
}

Configs set mentioned in error is defined as

// Configs is a config provider to auto wire
var Configs = wire.NewSet(ProvideLivePostgresConfig, ProvideLiveMediaHandlerConfig)

Expected behavior

I would expect it to provide the type returned when throwing error message, *invalid type is not telling anything for debugging.

Version

github.com/google/wire v0.2.2

[vangent]

Thanks for the report. More than likely this is a misconfiguration, but wire should give a better error message.

• Does this still happen if you upgrade to wire v0.3.0 ?
• Is there any relationship between livemediaobject.PostgresSQLConfig and livemediaobject.HandlerConfig, or are they just independent structs?
• Can you please include your wire.Build (near config.go:50)?

If you could provide a dumbed-down testcase (i.e., similar to the test in https://github.com/google/wire/tree/master/internal/wire/testdata/MultipleBindings), that would be really helpful.

[josgilmo]

I'm having a problem related with the upgrade of wire.

I created the situation in a repository https://github.com/josgilmo/wire-issue-214. With this wire configuration, if I build the birany wire with the tag v0.2.2 it works without problem, but with the binary generated with master it give me the error:

wire: /Users/josegil/go/src/github.com/josgilmo/wire-issue-214/wire.go:28:2: github.com/josgilmo/wire-issue-214/foo1.MongoGeolocation does not implement github.com/josgilmo/wire-issue-214/foo2.GeolocationReader wire: github.com/josgilmo/wire-issue-214: generate failed wire: at least one generate failure

I think that the configuration it's valid because wire worked perfect in the tag v0.2.2.

I tried to understand the reason and it seems that and I think that it's related with the change in the processBind in parse.go, but I couldn't to find a solution yet.

I hope this information it's helpful.

[vangent]

@josgilmo -- that doesn't seem to have anything to do with this issue, can you please file a new one? https://github.com/google/wire/issues/new

[josgilmo]

@vangent yes!