Skip to content

Fallback handle string BorshIoError for InstructionError#8582

Closed
BriungRi wants to merge 1 commit intoanza-xyz:masterfrom
BriungRi:fix/ui-transaction-error-robust-deserializer
Closed

Fallback handle string BorshIoError for InstructionError#8582
BriungRi wants to merge 1 commit intoanza-xyz:masterfrom
BriungRi:fix/ui-transaction-error-robust-deserializer

Conversation

@BriungRi
Copy link
Copy Markdown

@BriungRi BriungRi commented Oct 20, 2025

Problem

InstructionError from solana-instruction@2.3.0 doesn't have a way to parse the InstructionError from 3.x validators when it comes back as "BorshIoError". This is handled in a new crate, solana-instruction-error@2.0.0, but this commit makes it possible to backport it to the 2.3 branch without the crate addition/upgrade

Summary of Changes

Add fallback InstructionError parsing for "BorshIoError"

Fixes #8548

@mergify mergify Bot requested a review from a team October 20, 2025 22:04
@BriungRi BriungRi force-pushed the fix/ui-transaction-error-robust-deserializer branch from 8c0325f to 030aa7f Compare October 20, 2025 22:09
@BriungRi BriungRi changed the title [WIP] Make UiTransactionError deserializer robust across SDK versions Handle string BorshIoError Oct 20, 2025
@BriungRi BriungRi changed the title Handle string BorshIoError [WIP] Handle string BorshIoError Oct 20, 2025
@BriungRi BriungRi force-pushed the fix/ui-transaction-error-robust-deserializer branch from 030aa7f to 3c5a73b Compare October 20, 2025 22:30
@BriungRi BriungRi changed the title [WIP] Handle string BorshIoError [WIP] Backport InstructionError parsing fixes Oct 20, 2025
@BriungRi BriungRi force-pushed the fix/ui-transaction-error-robust-deserializer branch from 3c5a73b to 20df6dc Compare October 20, 2025 22:30
@BriungRi BriungRi changed the title [WIP] Backport InstructionError parsing fixes Handle string BorshIoError Oct 20, 2025
@BriungRi BriungRi marked this pull request as ready for review October 20, 2025 22:33
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 BriungRi force-pushed the fix/ui-transaction-error-robust-deserializer branch from 20df6dc to 94606c3 Compare October 20, 2025 22:37
@BriungRi BriungRi changed the title Handle string BorshIoError Fallback handle string BorshIoError for InstructionError Oct 20, 2025
@bw-solana bw-solana requested a review from t-nelson October 20, 2025 22:53
@bw-solana
Copy link
Copy Markdown

@t-nelson the only point of this would be for a v2.3 backport for compatibility, so might as well get ahead of things w/ any feedback

@steviez
Copy link
Copy Markdown

steviez commented Oct 20, 2025

Hi @BriungRi - I haven't reviewed the actual PR yet, but in the future, please try to get the commits & branch a bit more "ready" before creating the PR. I see a bunch of force pushes and PR renames in a pretty short span

@t-nelson
Copy link
Copy Markdown

"fixes" issue seems unrelated. where is solana-instruction-error-3.0.0? i only see 2.0.0 on crates and diff from its tag to tip of master in sdk repo only marks the module as deprecated (unfortunately with no since or note fields populated)

@BriungRi
Copy link
Copy Markdown
Author

BriungRi commented Oct 21, 2025

@t-nelson I had a bad description. Went back and found the crates and versions between master and 2.3.

master is using InstructionError from solana-instruction-error@2.0.0
2.3 is using InstructionError from solana-instruction@2.3.0

@t-nelson
Copy link
Copy Markdown

@joncinque @kevinheavey was there an existing migration plan for this change?

@joncinque
Copy link
Copy Markdown

To be honest, I thought it would Just Work since we weren't storing these, so there was no specific plan.

I think the easiest way forward is to land something like this, backport it to v3, and then backport the inverse change to v2.3, ie add an empty string if an empty BorshIoError is found. This way, all of the changes are confined to the conversions, and clients just need to update.

If that approach sounds good, I'll take over reviews for this PR and help get backports through.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Potentially inconsistent data when calling crds.push_message(entry)

5 participants