[WIP] Backport InstructionError parsing fixes#8581
[WIP] Backport InstructionError parsing fixes#8581BriungRi wants to merge 2 commits intoanza-xyz:v2.3from
InstructionError parsing fixes#8581Conversation
* Add `UiTransactionError` and `UiTransactionResult` * Fixup callsites and tests * Review feedback * Changed CLI types to use `UiTransactionError` * Eliminated `UiTransactionResult` in favour of `Result<(), UiTransactionError>` * Implemented `std::error::Error` on `UiTransactionError` which just forwards to `TransactionError` * Implemented `fmt::Display` on `UiTransactionError` which just forwards to `TransactionError` * Made the inner error private on `UiTransactionError` * Eliminated `Deref` implementation, requiring explicit conversion * * Results, all the way down * Make the `InstructionError` deserialize actually work by taking all of the bytes * Remove stray dependency * Fix the deserializer
InstructionError parsing fixes
d3883e8 to
178d549
Compare
Enhance the InstructionError deserializer within UiTransactionError to handle
both unit variant and newtype variant serialization formats. This improves
compatibility when deserializing errors from different SDK versions.
Specifically handles the case where BorshIoError may be serialized as:
- Unit variant: "BorshIoError" (SDK v2.0+)
- Newtype variant: {"BorshIoError": "message"} (older SDKs)
The deserializer now tries the direct deserialization first (handles unit
variants), and falls back to converting the format if needed (handles newtype
variants in older SDKs).
This defensive coding ensures forward and backward compatibility across SDK
version boundaries.
|
@BriungRi - Can you comment on why you opened another PR against v2.3 given @bw-solana's comment from #8579 (comment) ? |
Setting up a PR on GH lets me visually validate the two commits I've selected are valid backports from master to 2.3. If this were my own repo, it also lets me run CI against these commits too. FWIW, this is a draft PR and not meant for review. |
Since you're not an Anza member, several people get notifications when you open a PR or update it (push, comment, rename, etc). And even more people for this commit since it is against the If you have a noisy PR, people are likely to unsubscribe from it which could result in your PR later getting ignored if/when you do actually want a review.
I see. If you just want the diff, you can do
If you're commenting on whether they apply cleanly, you can do: The CLI will yell at you if there is a merge conflict
Yeah, we intentionally limit who gets CI run automatically since we've unfortunately had abuse in the past. |
Problem
Summary of Changes
Fixes #