Should we support fallback() in an auto resolve mode contract

[syntrust]

The following link is supported by the old version of web3url-gateway but not new version web3protocol-go:

https://0x31caefa22959db0581623618d9c554e6436aa4b4.w3q-g.w3link.io/0x6d4a199f603b084a2f1761dc9f322f92e68bfd5e-demo.png

The reason is the contract extends ERC5018 but overrides resolveMode as "auto" for some implementation convenience. In this case, the old gateway calls fallback() of the contract, while the new one reports "invalid method name":

https://github.com/ethstorage/w3music/blob/65f2e8d21c09ad63b0057af011b70164f8eba192/contract/SimpleW3Music.sol#L2094

How should we handle this case, since EIP-4804 seems to have no specific description about it?

[qizhou]

If it is in auto mode, I believe that we should not call fallback() as specified by ERC-4804 (or ERC6860 for the latest), right?

BTW: I think we should just call the contract with the method signature, but not sure why it returns "invalid method name".?

[syntrust]

If it is in auto mode, I believe that we should not call fallback() as specified by ERC-4804 (or ERC6860 for the latest), right?

BTW: I think we should just call the contract with the method signature, but not sure why it returns "invalid method name".?

The engine considers 0x6d4a199f603b084a2f1761dc9f322f92e68bfd5e-demo.png part not a valid method name with regular expression.

[qizhou]

Indeed - we should follow the method name defined in ABI where 0x6d4a199f603b084a2f1761dc9f322f92e68bfd5e-demo.png is not a valid method name.

[nand2]

Yes indeed, since it is auto mode, it checks that the method name (here, 0x6d4a199f603b084a2f1761dc9f322f92e68bfd5e-demo.png) follows the allowed syntax of method names as defined in https://docs.soliditylang.org/en/latest/grammar.html#a4.SolidityLexer.Identifier

[syntrust]

Close as the conclusion is no.