Add support for calling private view functions

[xbtmatt]

Description

Private view functions, e.g. a function like the following:

#[view]
fun hidden_from_abis(): u64 {
    0
}

are callable off-chain the same way private entry functions are. However, they aren't included in the module's function ABIs. You can confirm this here with a simple curl request (included jq for easy viewing):

curl --request GET \
     --url https://api.testnet.aptoslabs.com/v1/accounts/0x635f592857fd8c57d10f92c49e858ad6f4e92b3d24ec521fccad459289f38208/module/main \
     --header 'Accept: application/json' | jq -r .

You should see an empty exposed_functions array, but you can still call the function:

aptos move view --function-id 0x635f592857fd8c57d10f92c49e858ad6f4e92b3d24ec521fccad459289f38208::main::hidden_from_abis --url https://fullnode.testnet.aptoslabs.com

Which returns with:

{
  "Result": [
    "0"
  ]
}

Note that the reason this wasn't an issue before is because view functions weren't BCS-serializable and thus did not use the fetchABIs call

Changes

The SDK currently checks the ABIs regardless of what's passed in to view. This means that there's no way to call a private view function, even if you already have the ABIs or the serialized entry function arguments.

In order to circumvent this, I've updated view in src/internal/view.ts to check if an abi is passed in. If so, it circumvents the ABI lookup failure in generateViewFunctionPayload by calling generateViewFunctionPayloadWithABI directly.

The most relevant changes are below:

// Skip ABI fetch (and thus the error) and use ABIs passed in, run ABI checks still
if (typeof abi !== "undefined") {
   viewFunctionPayload = generateViewFunctionPayloadWithABI({
      ...payload,
      abi,
   });
}
// Otherwise, check if every argument is BCS-encoded
else {
   const everyFunctionArgumentIsEncoded = payload.functionArguments?.every(isEncodedEntryFunctionArgument);
   // If so, skip ABI fetch/check, serialize arguments directly
   if (everyFunctionArgumentIsEncoded) {
      viewFunctionPayload = await generateViewFunctionPayloadWithNoABI({
         ...(payload as InputViewFunctionDataWithNoABI),
         functionArguments: payload.functionArguments as Array<EntryFunctionArgumentTypes>,
      });
   // Otherwise make the call like it is made right now, with the potential for error
   } else {
      try {
         viewFunctionPayload = await generateViewFunctionPayload({ ... });
      } catch (e) {
         // if (ViewFunctionNotFoundError) throw more specific error msg. see code
      }
   }
}

I've also added type discriminators in src/transactions/types.ts to discourage incorrect combinations at compile time if the user decides to invoke any of the generateViewFunctionPayload_ functions directly.

Test Plan

Now that view functions are BCS-serializable, I added unit tests in transactionArguments.test.ts to cover them, as well as Move unit tests in the contract itself. I've also updated the module bytecode for the module used in transactionArguments.test.ts:

pnpm jest transactionArguments.test.ts

They cover all of the combinations of the ABI being provided/not provided and the arguments being simple, mixed, and serializable.

I also exposed a simple test-only clearMemoizedCache function to facilitate these unit tests, since memoization will cause errors with the previously-fetched ABIs

[0xmaayan]

I think this is a great first step in handling the abi/non-abi/remote-abi flow in the SDK. Just need to organize it a bit more and add some tests for the different view function use cases

[0xmaayan]

any reason for this change?

[xbtmatt]

yeah oops I actually meant to note this in the PR, I'm not sure if it's intended or not, but basically if you pass in your own abi it overwrites the fetched ABI because of the order of the spread on ...args

basically if you pass abi: undefined it ignores the fetched ABI and tries to use undefined

It's kind of a small thing, since most often people won't pass abi: undefined, but in my case I was doing that, I just figured if you're fetching it it should use the results

[0xmaayan]

can this logic live in the transactionBuilder.ts file instead of here?

[0xmaayan]

❤️

[0xmaayan]

I think it is time for us to create tests/e2e/api/view.test.tsx file, move this in there, and add bunch of tests with this abi non-abi functionality

[0xmaayan]

we can benefit from this logic for entry function also, I think the SDK currently fetches and parses the remote ABI even for submitting an entry function with encoded arguments - let's pull it into its own helper function

[0xmaayan]

does it override the messages being thrown from the transactionBuilder flow?