fix: narrow transaction message signer types#1851
Open
rajanpanth wants to merge 1 commit into
Open
Conversation
🦋 Changeset detectedLatest commit: 937db2a The changes in this PR will be included in the next version bump. This PR includes changesets to release 48 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 |
Member
|
That's not a bad design. @mcintyre94 wdyt? |
mcintyre94
approved these changes
Jul 22, 2026
mcintyre94
left a comment
mcintyre94
left a comment
Member
There was a problem hiding this comment.
I think this looks good, definitely think it was a mistake to accept the other signer types here. Just a small suggestion to make the feePayer exclusion more future proof.
Comment on lines
+44
to
+49
| feePayer: Readonly<{ | ||
| modifyAndSignTransactions?: never; | ||
| signAndSendTransactions?: never; | ||
| signTransactions?: never; | ||
| }> & | ||
| TransactionMessageWithFeePayer<TAddress>['feePayer']; |
Member
There was a problem hiding this comment.
Something we might like to do here is to make this defensive against a future signer type, by deriving the methods of TransactionSigner. I think we could do something like this:
type UnionKeys<T> = T extends unknown ? keyof T : never;
type TransactionSignerMethodKeys = Exclude<UnionKeys<TransactionSigner>, 'address'>;
type WithoutSignerMethods = { readonly [K in TransactionSignerMethodKeys]?: never };
type TransactionMessageWithNonSignerFeePayer<TAddress extends string = string> = Readonly<{
feePayer: TransactionMessageWithFeePayer<TAddress>['feePayer'] & WithoutSignerMethods;
}>;
BundleMonUnchanged files (150)
Total files change +1B 0% Final result: ✅ View report in BundleMon website ➡️ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Make
TransactionMessageWithSigners<TAddress, TSigner>enforce its signer type parameter for both fee payers and instruction account metas.Problem
Signer objects structurally satisfy the plain fee-payer and account-meta branches because their extra methods and
signerproperty do not make them incompatible. As a result, a transaction containing aTransactionModifyingSignercan satisfyTransactionMessageWithSigners<Address, TransactionPartialSigner>.Changes
@solana/signers.Testing
Before
The narrowed signer parameter can be bypassed through the plain structural union branches.
After
Mismatched fee-payer and instruction signers are rejected, while matching signers and plain non-signer account shapes remain accepted.
Related issue
Fixes #1036