You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To spin up a transaction plan executor, you may use the `createTransactionPlanExecutor` helper. This helper requires an `executeTransactionMessage` function that tells us how each transaction message should be executed when encountered during the execution process.
375
375
376
-
This function accepts a transaction message and must return an object containing the successfully executed transaction, along with an optional context object that can be used to pass additional information about the execution.
376
+
The `executeTransactionMessage` callback receives the following arguments:
377
+
378
+
-**`context`**: A mutable object for storing data during execution — see the [next section](#the-execution-context) for details.
379
+
-**`message`**: The transaction message to execute.
380
+
-**`config`**: An optional configuration object that may include an `abortSignal`.
381
+
382
+
The callback must return either a `Signature` or a full `Transaction` object directly.
377
383
378
384
For instance, in the example below we create a new executor such that each transaction message will be assigned the latest blockhash lifetime before being signed and sent to the network using the provided RPC client.
379
385
@@ -389,7 +395,7 @@ import {
389
395
signTransactionMessageWithSigners,
390
396
assertIsSendableTransaction,
391
397
assertIsTransactionWithBlockhashLifetime,
392
-
BaseTransactionMessage,
398
+
TransactionMessage,
393
399
TransactionMessageWithFeePayer,
394
400
} from'@solana/kit';
395
401
const rpc = {} asunknownasRpc<SolanaRpcApi>;
@@ -398,23 +404,109 @@ const rpcSubscriptions = {} as unknown as RpcSubscriptions<SolanaRpcSubscription
The `context` object passed to the `executeTransactionMessage` callback is a mutable object that you can populate incrementally as execution progresses. This context is preserved in the resulting `SingleTransactionPlanResult` regardless of the outcome — successful, failed, or canceled.
427
+
428
+
This is particularly useful for debugging failures or building recovery plans. If an error is thrown at any point in the callback, any attributes you've already saved to the context will still be available in the `FailedSingleTransactionPlanResult`.
429
+
430
+
The context object supports three optional base properties that have semantic meaning:
431
+
432
+
-**`message`**: The transaction message after any modifications (e.g., after setting a lifetime).
433
+
-**`transaction`**: The signed transaction ready to be sent.
434
+
-**`signature`**: The transaction signature. Note that this is automatically populated when you set the `transaction` property on the context and/or return a `Transaction`.
Check out the [Recipes section](#recipes) at this end of this guide for ideas of what can be achieved with this API.
419
511
420
512
### Transaction plan results
@@ -423,30 +515,34 @@ When you execute a transaction plan, you get back a `TransactionPlanResult` that
423
515
424
516
Each transaction message in your plan can have one of three execution outcomes:
425
517
426
-
-**Successful** - The transaction was sent and confirmed. You get the original transaction message, the executed `Transaction`object and any context data.
427
-
-**Failed** - The transaction encountered an error. You get the original transaction message and the error that caused the failure.
428
-
-**Canceled** - The transaction was skipped because an earlier transaction failed or the operation was aborted. You only get the original transaction message.
518
+
-**Successful** - The transaction was sent and confirmed. You get the original planned message, a context object containing the signature (and optionally the transaction), plus any custom context data.
519
+
-**Failed** - The transaction encountered an error. You get the original planned message, the error that caused the failure, and a context object with any data accumulated before the failure.
520
+
-**Canceled** - The transaction was skipped because an earlier transaction failed or the operation was aborted. You get the original planned message with any context data accumulated before cancellation.
429
521
430
522
The result structure mirrors your transaction plan structure:
431
523
432
-
- Single transaction messages become `SingleTransactionPlanResult` with the original message plus execution status
524
+
- Single transaction messages become `SingleTransactionPlanResult` with the original `plannedMessage` plus execution status
433
525
- Sequential plans become `SequentialTransactionPlanResult` containing child results
434
526
- Parallel plans become `ParallelTransactionPlanResult` containing child results
435
527
528
+
Each `SingleTransactionPlanResult` has a `status` property that is a string literal (`'successful'`, `'failed'`, or `'canceled'`), and properties like `context`, `error` live at the top level of each variant.
0 commit comments