locals App reference 0 outside tx.Access #6449
Description
I'll start by saying if you construct a transaction which does include the current application ID in the access list and it's referenced/indexed by the locals reference, then things work as you'd expect. But using goal doesn't provide that behaviour, so I'm not sure if it's expected or not.
When constructing an application call that uses a locals resource, if you supply zero or the current Application ID for the app, the resulting references omits an app reference/index. This seemed reasonable, as a value of 0 usually means the application itself or sender, and comments I found here seemed to suggest that's the case.
goal app call --app-id 1018 --from ALICE7Y2JOFGG2VGUC64VINB75PI56O6M2XW233KG2I3AIYJFUD4QMYTJM --local 1018+BOBBYB3QD5QGQ27EBYHHUT7J76EWXKFOSF2NNYYYI6EOAQ5D3M2YW2UGEA --access
# msgpack decode:
...
"al": [
{
"d:b64": "C4IcB3AfYGhr5A4Oek/p/4lrqK6RdNbjGEeI4EOj2zU="
},
{
"l": {
"d": 1
}
}
],
...But data/transactions/application.go fails to pass the wellFormed checks, with the error: locals App reference 0 outside tx.Access.
I have found it is libgoal's attachAccessList that's keeping appIdx as 0, and not ensuring the current application ID is added. But as I mentioned at the top, if you modify the transaction's access list to include the current application ID and index to it, then the transaction will work.
...
"al": [
{
"d:b64": "C4IcB3AfYGhr5A4Oek/p/4lrqK6RdNbjGEeI4EOj2zU="
},
{
"p": 1018
},
{
"l": {
"d": 1,
"p": 2
}
}
],
...