You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Anchor allows accessing accounts not defined on the Accounts struct through ctx.remaining_accounts. I currently don't see a way to pass these additional accounts in the generated client code cleanly.
Proposal:
Add optional arg to pass additional accounts
I have thought about this but the reason I didn't add it in is because the remaining accounts aren't in the IDL so there's no way to generate anything useful here.
The way to go is to add them to the returned TransactionInstruction as you mentioned:
I would argue that this is cleaner than adding an optional remainingAccounts arg to every instruction method especially since in 99% of the cases you won't use them.
Ultimately you shouldn't have to use resort to remaining accounts but there's a lot of use cases where you have to pass accounts optionally and anchor doesn't support this currently. In fact I would argue that using remaining accounts in your contract is already a workaround.
So this should be addressed by adding proper support for optional or variable number of accounts in anchor IMO and then we can generate something useful here. In the meantime adding them to TransactionInstruction seems like a good approach to me.
May I ask why you have to resort to remaining accounts in your contract?
I'm writing a cross-chain proxy contract and want to use a single generic instruction to deal with multiple proxied instructions. The alternative is closely coupling the proxy contract to the target contract, which is ok, but not ideal.
Anchor allows accessing accounts not defined on the Accounts struct through
ctx.remaining_accounts
. I currently don't see a way to pass these additional accounts in the generated client code cleanly.Proposal:
Add optional arg to pass additional accounts
Haven't tried it yet, but I believe there's a workaround where the returned TransactionInstruction can be mutated, but this is non-ideal
The text was updated successfully, but these errors were encountered: