Formatting errors on ETH-like networks

[FrederikBolding]

We've been having an issue with fetching transaction receipts on ETH-like networks for the new version of MyCrypto. The problem occurs because networks like RSK return an invalid root for transaction receipts which isn't a valid hash. (There may be other such formatting errors on other networks)

The error in question:
invalid hash (arg="hash", value="0x01", version=4.0.48)

Would it be possible to have settings for looser formatting requirements to use ethers.js with more networks? For our use-case we don't necessarily always care that the receipt upholds the entire formatting requirement.

Thanks for building such a great library! ❤️

[zemse]

Maybe you can use raw rpc as a work around.

// raw rpc result (unformatted)
const result = await provider.send('eth_getTransactionReceipt', ['0xYourTxHash']);

[FrederikBolding]

For now we've ended up doing a hack described here: rsksmart/rskj#1328 (comment)

Our implementation of that is here:
https://github.com/MyCryptoHQ/MyCrypto/blob/master/src/services/EthService/network/providerHandler.ts#L115-L118

Would however prefer that this was handled by ethers 😄

[ricmoo]

Can you provide a JSON-RPC url and a transaction hash used to reproduce this?

My guess is this is related to #952, but I haven't been able to reproduce it. I think it is caused by a non-Ethereum network incorrectly implementing EIP-658, but it is something I can adjust for, if I can reproduce it.

Also, you are using a very old version of ethers, you should try updating to a more recent version (although I do not expect that to solve this issue) since I won't port this change back to v4, it would only be available in v5 anyways. :)

Thanks in advance! :)

[bguiz]

My guess is this is related to #952, but I haven't been able to reproduce it.

Yes, this does indeed look like the same/ similar error I've been running into.

See: #952 (comment)

[FrederikBolding]

Can you provide a JSON-RPC url and a transaction hash used to reproduce this?

My guess is this is related to #952, but I haven't been able to reproduce it. I think it is caused by a non-Ethereum network incorrectly implementing EIP-658, but it is something I can adjust for, if I can reproduce it.

Also, you are using a very old version of ethers, you should try updating to a more recent version (although I do not expect that to solve this issue) since I won't port this change back to v4, it would only be available in v5 anyways. :)

Thanks in advance! :)

We bumped Ethers to v5 recently, so that shouldn't be an issue 👍

You can try using eth_getTransactionReceipt on 0x1eb618c304116932b643daefdd85ee35dbab6192f4d8c5cde2a15cf8bf90c58e via this node: mycrypto.rsk.co. That is how I reproduced it initially.

[ricmoo]

I've updated the (closed) issue on RSK. If someone knows the right person to bug to re-open, please go ahead and do that.

I've added logic locally that correct this. I'm just testing it out right now.

[ricmoo]

This should be addressed in 5.0.27. Please try it out and let me know if you still have any issues.

Thanks! :)

[FrederikBolding]

Looks to be working! I will be bumping our version and removing the hack that we used. I'll report back if we see any further issues! Thanks for the fast response!

[ricmoo]

Awesome!

Thanks! :)