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

Provide useful error when a type can't be resolved but there are matching types in unreferenced modules #11909

Closed
Tracked by #11899
aaronc opened this issue May 9, 2022 · 1 comment
Labels
C:depinject Issues and PR related to depinject

Comments

@aaronc
Copy link
Member

aaronc commented May 9, 2022

Similar to #11908, we can provide a useful error when there are app modules outside the container which could satisfy a required interface, for instance:

Provider provideNFTModule requires bank.Keeper. The following module(s) provide that type:
  cosmos.bank.module.v1.Module
@aaronc aaronc added the C:depinject Issues and PR related to depinject label May 9, 2022
@tac0turtle tac0turtle moved this to 📝 Todo in Cosmos-SDK May 9, 2022
@kocubinski kocubinski self-assigned this Aug 17, 2022
@kocubinski
Copy link
Member

Given that module registration happens on import in init functions, I'm not understanding how depinject could know of an output but not fetch it as input?

@kocubinski kocubinski removed their assignment Aug 24, 2022
@tac0turtle tac0turtle moved this to 👀 To Do in Cosmos-SDK Nov 16, 2023
@github-project-automation github-project-automation bot moved this from 📋 Backlog to 🥳 Done in Cosmos-SDK Apr 22, 2024
@tac0turtle tac0turtle removed this from Cosmos-SDK Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:depinject Issues and PR related to depinject
Projects
None yet
Development

No branches or pull requests

3 participants