Added type guards for legacy and v0 transaction message types #1103
Conversation
🦋 Changeset detectedLatest commit: c21d6b8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 42 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 |
* Added isLegacyTransactionMessage and assertIsLegacyTransactionMessage helpers to packages/transaction-message * Added isV0TransactionMessage and assertIsV0TransactoinMessage helpers to packages/transaction-message
a11414e to
c21d6b8
Compare
steveluscher
left a comment
There was a problem hiding this comment.
Can you talk a little bit more about why this is necessary? With small modifications, your typetests (thanks for writing typetests!) already work against the current version of Kit.
|
Hi @steveluscher, thanks for getting back to me. So the implementation is the following: export async function injectSolFeeIntoTx(
env: Env,
swapTransactionB64: string,
feeInstruction: Instruction,
): Promise<string> {
const client = getClient(env);
const base64Encoder = getBase64Encoder();
const transactionBytes = base64Encoder.encode(swapTransactionB64);
const txDecoder = getTransactionDecoder();
const tx = txDecoder.decode(transactionBytes);
const compiledMsgDecoder = getCompiledTransactionMessageDecoder();
const compiledMsg = compiledMsgDecoder.decode(tx.messageBytes);
const lutAddresses =
compiledMsg.version === 0
? (compiledMsg.addressTableLookups?.map((l) => l.lookupTableAddress) ??
[])
: [];
const decompiledMsg = await decompileTransactionMessageFetchingLookupTables(
compiledMsg,
client.rpc,
);
const msgWithFee = appendTransactionMessageInstructions(
[feeInstruction],
decompiledMsg,
);
const addressesByLookupTableAddress = lutAddresses.length
? await fetchAddressesForLookupTables(lutAddresses, client.rpc)
: {};
const compressedMsg =
Object.keys(addressesByLookupTableAddress).length > 0 &&
msgWithFee.version === 0
? compressTransactionMessageUsingAddressLookupTables(
// casting as we know this is a version 0 tx msg
msgWithFee as typeof msgWithFee & { version: 0 },
addressesByLookupTableAddress,
)
: msgWithFee;
const txWithFee = compileTransaction(compressedMsg);
return getBase64EncodedWireTransaction(txWithFee);
}Here, checking |
|
@mcintyre94, I think there's a problem with the return type of The return type there is The playground to make work is (link) |
|
Sorry for the delay on this, taking a look! |
#### Problem When we use `decompileTransactionMessage`, we get a `BaseTransactionMessage`, which is not a union type and therefore doesn't play nicely with Typescript type narrowing by version. #### Summary of Changes - Improve the typing of `decompileTransactionMessage` - Add typetests Part of a stack that eventually supersedes #1103
…upTables (#1133) #### Problem When we use `decompileTransactionMessageFetchingLookupTables`, we get a `BaseTransactionMessage`, which is not a union type and therefore doesn't play nicely with Typescript type narrowing by version. #### Summary of Changes - Improve the typing of `decompileTransactionMessageFetchingLookupTables` - Add typetests Part of a stack that eventually supersedes #1103
…tions (#1134) #### Problem Our `TransactionMessage` functions operate on `BaseTransactionMessage` instead of `TransactionMessage`, which limits the ability to type narrow the resulting transaction messages #### Summary of Changes - Change to use `TransactionMessage` in input/output types Part of a stack that eventually supersedes #1103
…functions (#1135) #### Problem Our `TransactionMessage` functions operate on `BaseTransactionMessage` instead of `TransactionMessage`, which limits the ability to type narrow the resulting transaction messages #### Summary of Changes - Change to use `TransactionMessage` in input/output types Part of a stack that eventually supersedes #1103
…ions (#1136) #### Problem Our `TransactionMessage` functions operate on `BaseTransactionMessage` instead of `TransactionMessage`, which limits the ability to type narrow the resulting transaction messages #### Summary of Changes - Change to use `TransactionMessage` in input/output types Part of a stack that eventually supersedes #1103
…nctions (#1137) #### Problem Our `TransactionMessage` functions operate on `BaseTransactionMessage` instead of `TransactionMessage`, which limits the ability to type narrow the resulting transaction messages #### Summary of Changes - Change to use `TransactionMessage` in input/output types Part of a stack that eventually supersedes #1103
#### Problem Our `TransactionMessage` functions operate on `BaseTransactionMessage` instead of `TransactionMessage`, which limits the ability to type narrow the resulting transaction messages #### Summary of Changes - Change to use `TransactionMessage` in input/output types Part of a stack that eventually supersedes #1103
#1139) This PR adds a new typetest that does the following: - Decompile a transaction message using `decompileTransactionMessageFetchingLookupTables` - Apply each function that modifies a transaction message - Verify that it can still be type narrowed correctly Note that we don't have any typetests like this that combine functionality from multiple packages. I've put this in `packages/kit/__typetests__/scenarios`, but don't feel strongly about where it should live. I do think it's important to have this as part of the repo though because it would be very easy to introduce a regression. Supersedes #1103, by avoiding the need to introduce assertion functions
|
@joefitter Thanks for this, and especially for the typetests and detailed explanation. I've merged a stack of PRs that should remove the need for these new functions, by making it so that you can branch on See https://github.com/anza-xyz/kit/blob/6dbaf66015198bd912ec0800c1db1fd63b68e7a2/packages/kit/src/__typetests__/scenarios/transaction-message-decompile-modify-typetest.ts for a test of this I'll close this PR because I don't think we need to add these functions now, but thanks again for all your help here! |
|
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
Currently there are no type guards for transaction message version, so simply checking
message.versionin an implementation doesn't coerce type.Summary of Changes
Added
isLegacyTransactionMessage,assertIsLegacyTransactionMessage,isV0TransactionMessageandassertIsV0TransactionMessagealong with associated errors.