Unable to read SRC7 metadata via the TS SDK

[Dhaiwat10]

Incoming from this forum post: https://forum.fuel.network/t/metadat-read-fail/4197

When we try to read Metadata from a SRC7-compliant contract, the SDK crashes with the following error:

Uncaught (in promise) RevertError: The script reverted with reason Unknown
    at revertErrorFactory (index.mjs:206:14)
    at RevertErrorCodes.getError (index.mjs:235:12)
    at RevertErrorCodes.assert (index.mjs:219:30)
    at new ScriptResultDecoderError (index.mjs:265:43)
    at decodeCallResult (index.mjs:375:11)
    at decodeContractCallScriptResult (index.mjs:576:95)
    at FunctionInvocationResult.getDecodedValue (index.mjs:703:28)
    at new InvocationResult (index.mjs:677:23)
    at new FunctionInvocationResult (index.mjs:746:5)
    at FunctionInvocationResult.build (index.mjs:764:22)
    at async Object.readMetadata [as onPress] (index.tsx:47:17)

Setting Metadata works fine though.

[Torres-ssf]

@Dhaiwat10 I was investigating this yesterday and I am going to share my findings with you:

Just like we already validated, setting the Metadata works, but when trying to get it, the TX is reverted.

The Metadata enum is defined here

So when setting a Metadata we have the option to do so using one of these types: Int, String, B256, and Bytes.

On the forum post, the error is happening when using the String type. So I've tried the other 3:

1 Int: Works both when setting and retrieving it, e.g:

const metadata = {
  Int: 100,
}

2 B256: Also works both when setting and retrieving it. e.g:

const metadata = {
  B256: getRandomB256(),
}

3 Bytes: Works when setting and retrieving it, however, the returned result is always an empty array.

const metadata = {
  Bytes: [40, 41, 42],
}

It is weird that the returned value by the fn metadata is an empty array. It is worth validating if the issue is on the TS-SDK side.

cc @danielbate

4 String: Works for setting but it always reverts when retrieving. I have also tried some different strings.

const metadata = {
  String: "fuel",
}

I am inclined to believe that the problem here is not coming from the TS-SDK side.

I hope these findings might help you in some way 🫡

[Dhaiwat10]

Thanks @Torres-ssf, that is indeed super helpful information. My investigations are giving me similar feelings as well.

I am especially skeptical about this being a TS SDK issue in the first place because the transaction to read something is reverting. If there was a problem in the encoding/decoding logic of the TS SDK, you would expect the set_metadata function to revert if the encoding was wrong, and there would be no reason for the transaction to revert if there was an issue with the decoding logic since it only happens after the transaction has taken place.

Your finding about Bytes got me thinking that there might be a possibility that because of some flawed encoding logic for the set_metadata input, the TS SDK is not supplying proper inputs and hence not setting the metadata properly - which might be what's causing the read tx to revert when it does revert. I'm gonna investigate this further.

[danielbate]

The problem here is that bytes in this context is a nested heap type, not supported in v0. This is solved in v1 and proved in #1832.

[chappie1998]

@danielbate, when will there be a release with this fixed?

[danielbate]

@chappie1998 I'm afraid we can't give an exact release date for this at the moment. The new encoding scheme is part of a wider piece of work, so requires aligning changes and releases with many products in our eco-system.

But as you can see, it is in active development and we will keep this issue up to date and can coordinate with yourself. #1672 also details the v1 changes within the TS SDK realm.

[chappie1998]

Hey, @danielbate, are these changes out with the latest release on both the sway and SDK side?

[danielbate]

So this was included in v0.80.0 of the SDK. And v0.53.0 of forc. You will need to build your programs with --experimental-new-encoding.

As the flag suggests, this work is currently experimental so you may experience some unexpected behaviour, but it would be really helpful for you to try it out and feedback any problems.

One issue we are already aware of tho, is that it currently does not support multicall, that will be included in #2050.