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

Improve caller_address usage in read_only API #4651

Open
Leo-Besancon opened this issue Feb 21, 2024 · 0 comments · May be fixed by #4652
Open

Improve caller_address usage in read_only API #4651

Leo-Besancon opened this issue Feb 21, 2024 · 0 comments · May be fixed by #4652
Assignees
Labels
api Issues related to the API enhancement New feature or request

Comments

@Leo-Besancon
Copy link
Contributor

When calling execute_read_only_call (and probably the same is true for execute_read_only_bytecode), the caller_address is optionnal. If we do not provide one, it is generated randomly by the node.

This is good because sometimes we are sure that the call does not depend on the caller_address. However, it may lead to difficult to debug errors if the address is expected to be in the ledger.

If fee or coins argument is present, it will lead to the following error, as the randomly generated address does not exist in the ledger:

readonly call failed: Runtime error: spending address AU1KACmd3HvyqcqK4LDmhtSmoHnEiMmS7e4xHrzAx97AMCafdhLf not found"

TODO:

  • Provide a better error if fee or coins is set but not caller_address
  • See if other improvements can be made
@Leo-Besancon Leo-Besancon self-assigned this Feb 22, 2024
@Leo-Besancon Leo-Besancon linked a pull request Feb 22, 2024 that will close this issue
8 tasks
@AurelienFT AurelienFT added enhancement New feature or request api Issues related to the API labels Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Issues related to the API enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants