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

lang: improve AccountNotProgramOwned error msg or add new error #1100

Closed
paul-schaaf opened this issue Dec 4, 2021 · 6 comments · Fixed by #1154
Closed

lang: improve AccountNotProgramOwned error msg or add new error #1100

paul-schaaf opened this issue Dec 4, 2021 · 6 comments · Fixed by #1154
Labels
help wanted Extra attention is needed lang

Comments

@paul-schaaf
Copy link
Contributor

Current error msg is:

The given account is not owned by the executing program

But Account can also wrap types that are owned by a different program (same for AccountLoader)

how about

The given account is owned by a different program than expected
@losman0s
Copy link
Contributor

Do we want to change the wording of the error enum as well (could break some projects), from AccountNotProgramOwned to AccountOwnedByWrongProgram for instance, or is the current one accurate enough?

@paul-schaaf
Copy link
Contributor Author

@losman0s AccountOwnedByWrongProgram sgtm

@losman0s
Copy link
Contributor

@paul-schaaf For my sanity, do you have a concrete example/scenario where the current error would be thrown and be misleading?

@paul-schaaf
Copy link
Contributor Author

@losman0s when you have an Account<'info, Data> in your derive Accounts struct and Data comes from a different anchor program Zand the account passed in does not have the id of that program, you currently get the error The given account is not owned by the executing program even though the account you expect is not owned by the executing program but by program Z

@losman0s
Copy link
Contributor

@paul-schaaf Ok, so the macro behaves correctly, and just reports confusingly. i.e: when we specify through the Data account's validation macro that we expect it to be owned by z, but that it is found to belong to y, it does throw, but reports the confusing message.

@paul-schaaf
Copy link
Contributor Author

@losman0s correct

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed lang
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants