Deprecate invocations of isProgramError that rely on the user supplying a transaction message to decode the error#513
Conversation
🦋 Changeset detectedLatest commit: 39662f2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 40 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
BundleMonFiles updated (7)
Unchanged files (120)
Total files change +822B +0.23% Final result: ✅ View report in BundleMon website ➡️ |
|
Documentation Preview: https://kit-docs-24elr27gv-anza-tech.vercel.app |
ab226d4 to
63a1461
Compare
4a22f52 to
3f1fc8d
Compare
63a1461 to
9fe7733
Compare
…ying a transaction message to decode the error
3f1fc8d to
39662f2
Compare
|
Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up. |

Problem
isProgramErrorused to return unreliable results in cases where the error actually originated from a cross-program invocation (CPI). Now that the validator supplies the actual responsible program address in error responses, we can fix this.Summary of Changes
Deprecated the old call signature of
isProgramErrorand taught it to use the newresponsibleProgramAddressproperty ofSolanaErrordirectly.Depends on anza-xyz/agave#6083
Fixes #149