-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Add SDK support for creating transactions with address table lookups #23728
Conversation
5a331a9
to
924ede5
Compare
6ad1047
to
e1673e1
Compare
e1673e1
to
39e1242
Compare
) -> Result<Vec<CompiledInstruction>, CompileError> { | ||
let mut account_index_map = BTreeMap::<&Pubkey, u8>::new(); | ||
for (index, key) in self.iter().enumerate() { | ||
let index = u8::try_from(index).map_err(|_| CompileError::TooManyAccountKeys)?; |
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.
let's improve self-doc with an explicit constant for max supported, rather than implicitly relying on u8::MAX
.
Also seems like we should be preventing a too large AccountKeys
from ever being created rather than checking it here (and presumably other places in the future)
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.
There's a runtime limit of 64 but this compile error is for correctness not for runtime validity. I just want to make sure that the index actually fits in a u8
because that's how we serialize it in a transaction. There's many ways to create an invalid transaction on the client side so I think it's ok for now to allow large AccountKeys
to be created because they will be rejected during sanitization and the runtime check could change in the future so I don't want to hardcode that into the client.
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.
hmm, the error seems misleading in that case since we can have too many account keys without getting a TooManyAccountKeys
🤔
i typically prefer to fail asap rather than let pathology fester until some other process notices later. killing it at the client, especially in the first implementation, which the others will copy seems like the less wrong thing to do
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.
hmm, the error seems misleading in that case since we can have too many account keys without getting
TooManyAccountKeys
🤔
Agreed, that was a bad name. I updated to AccountIndexOverflow
and AddressTableLookupIndexOverflow
.
i typically prefer to fail asap rather than let pathology fester until some other process notices later. killing it at the client, especially in the first implementation, which the others will copy seems like the less wrong thing to do
I'm hesitant to do runtime checks on the client because runtime rules can change over time. For example, the serialized size of a transaction could change, the total number of accounts lockable by a transaction (currently 64) could be updated later, etc.
d090ae5
to
05c90a5
Compare
05c90a5
to
e066c6a
Compare
@t-nelson can you take another look? CI failure is unrelated to this change |
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.
lgtm, just a nit
a rebase should get you past that downstream build error
800170d
to
dece769
Compare
automerge label removed due to a CI failure |
Yay new downstream build failure:
|
dece769
to
04a7a8a
Compare
automerge label removed due to a CI failure |
04a7a8a
to
e0771ee
Compare
…olana-labs#23728) * Add SDK support for creating transactions with address table lookups * fix bpf compilation * rename compile error variants to indicate overflow * Add doc tests * fix bpf compatibility * use constant for overflow tests * Use cfg_attr for dead code attribute * resolve merge conflict
…olana-labs#23728) * Add SDK support for creating transactions with address table lookups * fix bpf compilation * rename compile error variants to indicate overflow * Add doc tests * fix bpf compatibility * use constant for overflow tests * Use cfg_attr for dead code attribute * resolve merge conflict
…olana-labs#23728) * Add SDK support for creating transactions with address table lookups * fix bpf compilation * rename compile error variants to indicate overflow * Add doc tests * fix bpf compatibility * use constant for overflow tests * Use cfg_attr for dead code attribute * resolve merge conflict
…olana-labs#23728) * Add SDK support for creating transactions with address table lookups * fix bpf compilation * rename compile error variants to indicate overflow * Add doc tests * fix bpf compatibility * use constant for overflow tests * Use cfg_attr for dead code attribute * resolve merge conflict
…olana-labs#23728) * Add SDK support for creating transactions with address table lookups * fix bpf compilation * rename compile error variants to indicate overflow * Add doc tests * fix bpf compatibility * use constant for overflow tests * Use cfg_attr for dead code attribute * resolve merge conflict
Problem
Rust SDK doesn't provide any convenience APIs for creating transactions which make use of on-chain lookup tables.
Summary of Changes
CompileError
error type to differentiate types of message compilation failuresMessage::try_compile
method to compile messages using address lookup tablesCompiledKeys::try_extract_table_lookup
to remove any non-signer compiled keys that can be replaced with an address table lookupAccountKeys::compile_instructions
is now fallible and was renamed toAccountKeys::try_compile_instructions
. It returns an error when compiling instructions with an unknown key or ifu8
conversion failsCompiledKeys::try_into_message_components
now returns aResult
instead of anOption
to make use of the newCompileError
Fixes #