[graphql-alt] Update Transaction return types for partial error support [3/n]

[tpham-mysten]

Description

Add partial error support for GraphQL resolvers in sui-indexer-alt-graphql by changing return types from Result<Option, E> to Option<Result<T, E>> for Transaction-related types.

Test plan

How did you test the new or updated feature?

cargo nextest run -p sui-indexer-alt-e2e-tests

---

Stack:

• [graphql-alt] Update Object return type to Option to support partial error response [1/n] #24595
• [graphql-alt] Update IAddressable return types for partial error support [2/n] #24681
• [graphql-alt] Update Transaction return types for partial error support [3/n] #24682 ⬅️
• [graphql-alt] Update Epoch return types for partial error support [4/n] #24683
• [graphql-alt] Update MoveModule return types for partial error support [5/n] #24684

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• Protocol:
• Nodes (Validators and Full nodes):
• gRPC:
• JSON-RPC:
• GraphQL: Partial error will be properly supported in GraphQL. Invalid fields will have error messages and valid fields will still be displayed normally
• CLI:
• Rust SDK:
• Indexing Framework:

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
multisig-toolkit	Ignored		Dec 18, 2025 5:40am
sui-kiosk	Ignored		Dec 18, 2025 5:40am

[amnn]

Seeing this makes me want to suggest adopting an even more standard pattern for these functions, namely to leave the bodies basically unchanged, and wrap them in one of these two patterns:

// Body doesn't produce optional values.
async {
  // ...
}
.await
.map(Some)
.transpose()

// Body could produce `None`
async {
  // ...
}
.await
.transpose()

You could even consider creating some! { ... } and transposed! { ... } macros for these, but I'm a bit on the fence about whether those would be actually useful.

[amnn]

Should we just inline the async block inside the Some as well?, e.g.

Some(async {
    // ...
}.await)