Can't specify arbitrary foreign accounts for method call

[jeron-diovis]

In a simplified way, my contract has following logic:

class Demo(Application):
    addressee = ApplicationStateValue(stack_type=TealType.bytes)

    @decorators.create
    def create(self, addressee: abi.Address):
        return Seq(
            self.addressee.set(addressee.get())
        )

    @decorators.external
    def notify(self):
        return Seq(
            InnerTxnBuilder.Execute({
                TxnField.type_enum: TxnType.Payment,
                TxnField.amount: Int(0),
                TxnField.note: Bytes("some notification"),
                TxnField.receiver: self.addressee.get(),
            })
        )

To make it work, addressee value must be explicitly submitted in accounts application array.

In python it works fine:

app = ApplicationClient(app=Demo(), app_id=..., ...)
app.call(Demo.notify, accounts=["whatever"])

In JS it doesn't:

import { Demo } from './beaker-generate/demo_client'
const app = new Demo({ appId: ..., ... })

app.notify({
  appAccounts: [ "whatever" ]
})

// still reports `logic eval error: invalid Account reference` error.

Which is because in JS SDK accounts field is composed internally, based on method args only. While appAccounts field is not used at all, despite it's declared as a valid TransactionOverrides parameter.

I can construct txn manually, using makeApplicationCallTxn directly.
But can't use ATC – and thus can't use beaker-ts ApplicationClient - with all the handy stuff it provides.

Is this a bug or there is some intent here?

[jeron-diovis]

Looks like there is an intent.
https://forum.algorand.org/t/javascript-sdk-atomictransactioncomposer-addmethodcall-missing-accounts-argument/7715

This will lead to a bloated interface (my app has 3 addresses in state, used in many methods), but, well, if rules say so, I'll rewrite it.

But, I'm curious – why py-SDK allows it then? It's really misleading, when same SDK behaves differently in different languages.
And appAccounts shouldn't be an allowed parameter for TransactionOverrides in ApplicationClient methods – although it's an issue for beaker-ts repo.

[barnjamin]

Once this is merged #725 you'll be able to do this.

Alternatively you could specify that the Address is of type Account instead, this would make the sdk machinery work as it is right now, but that might conflict with some already deployed contract?

[jeron-diovis]

@barnjamin My app is not released yet, so any experiments are ok. But I don't see how changing param type can help here, could you please explain it a bit?

And, as #725 is merged yesterday, when it is expected to be released?

[barnjamin]

The pr allows you to specify arbitrary accounts that are not included in the method signature of the ABI method. Once its tagged and released, beaker-ts can be updated to include it you'll be able to specify the accounts.

Until then an alternative for this specific instance would be for you to change the method signature of notify to expect an abi.Account argument and pass the account as a normal argument when calling it.