-
Notifications
You must be signed in to change notification settings - Fork 4.6k
rpc: Support token-2022 in token-specific calls #25150
Conversation
bytes: MemcmpEncodedBytes::Bytes(bytes), | ||
.. | ||
}) => { | ||
}) if *offset == account_packed_len && *program_id == inline_spl_token_2022::id() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about steering token-2022 users toward adding RpcFilterType::TokenAccountState
instead of a token-2022-specific memcmp?
Then it would be something like:
let mut token_account_state_filter: bool = false;
...
match filter {
RpcFilterType::TokenAccountState => {
token_account_state_filter = true;
}
...
}
if data_size_filter == Some(account_packed_len as u64) || token_account_state_filter {
...
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that makes way more sense. If someone does search on just the 165th byte though and it's possible to use an index, is it worth supporting that? Or should it use the normal getProgramAccounts implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I suppose there's no harm in supporting that (165th byte memcmp) filter for secondary indexes, and it does provide a way to use the secondary indexes to get only spl-token-2022
accounts, which could be useful.
So to be explicit regarding this...
if someone specifies one of those, should we assume that they actually want all token accounts or truly respect what they say?
I'm inclined to respect what they say, which is how your current code will work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My apologies, I hadn't read the whole thing and just assumed that it was simplifying the filter and not adding more filters. I added the token account state filter as you initially asked.
Codecov Report
@@ Coverage Diff @@
## master #25150 +/- ##
=========================================
Coverage 82.0% 82.1%
=========================================
Files 598 610 +12
Lines 165882 168068 +2186
=========================================
+ Hits 136125 138031 +1906
- Misses 29757 30037 +280 |
This is ready for another look, whenever you have a moment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this lgtm!
* rpc: Support token-2022 in token-specific calls * Address feedback (cherry picked from commit 0820065) # Conflicts: # account-decoder/src/parse_token.rs
* rpc: Support token-2022 in token-specific calls * Address feedback
* rpc: Support token-2022 in token-specific calls * Address feedback
* rpc: Support token-2022 in token-specific calls * Address feedback
Problem
While running tests for solana-labs/solana-program-library#3071 against master, there were still issues recognizing token-2022 accounts for some of the token-specific RPC endpoints.
Summary of Changes
Support token-2022 in a few more places in RPC. Most of the changes are tests.
A few changes that you might disagree with, so I want to flag them:
data[165] == 2
. if someone specifies one of those, should we assume that they actually want all token accounts or truly respect what they say?program_id
to the UiTokenAccount types, which is helpful in the CLI when figuring out dynamically which program id the account belongs toParsableAccount::SplToken2022
, and the program name that comes out is"spl-token-2022"