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

Handle decoding multi-contract logs gracefully #2004

Closed
petertonysmith94 opened this issue Apr 3, 2024 · 3 comments
Closed

Handle decoding multi-contract logs gracefully #2004

petertonysmith94 opened this issue Apr 3, 2024 · 3 comments
Assignees
Labels
bug Issue is a bug

Comments

@petertonysmith94
Copy link
Contributor

Issue

When dealing with multi-contracts (see this), users might call ContractA, which calls ContractB.

ContractA will require an ABI, ContractB will not. So, if ContractB has some log() calls, those may bubble up to ContractA, which won't be able to decode them due to the lack of an ABI definition, and then we throw.

The issue is that the transaction may have been successful, in which case throwing an error can be confusing.

Original Discussion.

Potential solutions

These solutions are worth considering, but requires more in-depth thought to understand if it can cause other problems.

  • We could print a warning instead of throwing an error when trying to decode ContractB logs as they come via ContractA.
    This approach could acknowledge the possible successful transaction while alerting the user to the decoding issue.

  • Maybe the better approach would be to not throw it here, and just log a warning.

@petertonysmith94
Copy link
Contributor Author

@arboleya I went with bug, but wasn't 💯, please change as you see fit 😄

@danielbate
Copy link
Contributor

Was this resolved by #1936?

@petertonysmith94
Copy link
Contributor Author

@danielbate yes - closed by #1936

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

No branches or pull requests

3 participants