Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Singleton resolvers that return error during resolution should not cache the concrete instance #57

Open
wbreza opened this issue Feb 13, 2024 · 0 comments

Comments

@wbreza
Copy link

wbreza commented Feb 13, 2024

Description

Singleton resolvers that return error during resolution should not cache the concrete instance

Steps to Reproduce

Given the following Go struct

type Foo struct {
    Value string
}

func NewFoo(value string) *Foo {
  return &Foo{ Value: value }
}

When using the container in this package if I register a resolver for a singleton where it could conditionally fail based on some expectation:

container.Singleton(func() (*Foo, error) {
  if expectationsAreMet {
    return NewFoo("test"), nil
  } else {
    return nil, errors.New("cannot create this type right now")
  }
})

Then when the caller attempts to re-resolve the type the cached nil value is returned instead of the resolver trying again.

var instance *Foo
err := container.Resolve(&instance) // Resolution can fail here if external expectation is not met
if err != nil {
  // Perform some bootstrapping to meeting required expectation
  external.MeetExpectation()
  
  // Try to resolve the type again after expectations are met
  err = container.Resolve(&instance) // Resolver should try again now that expectation has been met.
}

Expected

The registered singleton resolver should run again since the original resolution failed and return an error

Actual

The nil value is stored as the concrete value for the singleton and is returned on subsequent Resolve(...) calls.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant