-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Instruction Attribute cannot be shared between multiple composite structs #2942
Comments
is the solution to this is to just add documentation for this ? or we are still on the border of classifying it as a bug for a feature ? @acheroncrypto |
kinda confused how this is handled when the instruction takes in a parameter, it deserializes twice once in the instruction handler and secondly in the try_accounts handler for derive(accounts) struct,
@acheroncrypto not sure if the way deserialization occurs is the buffer gets updated with the same logic shdnt the deserialization fail in the try_accounts_handler since the same buffer is passed around, but if this works it should be able to work in composite structs as well ? but i cant figure out why it works in the try_accounts if the impl is for the ix data buffer to get updated after deserialization. |
After diving into the deserialization process in the Anchor framework which just uses borsh under the hood and reading the impl of read_exact, it seems the issue lies in shadowing the source buffer into a new mutable variable with Proposed SolutionInstead of shadowing the source buffer, we can use an immutable reference to the source buffer and pass a mutable reference to this immutable reference during deserialization. This way, the original buffer remains unchanged and reusable for further deserialization in the composite structs try_accounts impl. ImplementationCurrent approach: let mut __ix_data = __ix_data;
__Args::deserialize(&mut __ix_data)?; Proposed approach: __Args::deserialize(&mut &__ix_data[..])?; |
as per my p.o.v this seems a bug / wrong implementation, rather than a feature. |
Hey, sorry for taking long to reply to this.
At first glance, this makes sense, and we also do something similar in instruction handlers:
|
Problem :
the ix attribute under
fails if the parent derive accounts is composed of composite deriveAccounts, the reason is that while deserialization it takes a
&mut
refrence to the ix buffer and after deserializing it for the first time inParentAccountIx
pointer is updated so subsequent deserialization in other composite structs such asChildAccount
fails as the resulting buffer is updated to its past the fields the second ix requires and deserialization fails with error 102,this is the borsh deserilization trait which documents the updating of the buffer.
Note : I am unsure if this is a bug or just need to a limitation of composite structs that needs to be documented.
The text was updated successfully, but these errors were encountered: