This request is not supported because your node running with state pruning for Parity full history node

[vbaranov]

Description of the Issue

MyCrypto does not recognize a Parity full history node. The interaction with smart-contracts leads to an error "This request is not supported because your node is running with state pruning. Run with --pruning=archive."

Custom RPC provider endpoint: https://core-fullnode.poa.network Ethereum client: Parity-Ethereum//v2.2.1-beta-5c56fc5-20181114/x86_64-linux-gnu/rustc1.30.1

Pruning mode is disabled in configuration:

[footprint]
tracing = "on"
pruning = "archive"
fat_db = "on"

This endpoint works with Ethereum JSON RPC directly, MEW, MetaMask, Nifty Wallet.

Steps to Reproduce

• Add https://core-fullnode.poa.network/ to the list of custom nodes for POA
• Try to interact with any smart-contract in POA, for example, with 0x4316f704989157162de90997ce1a05cff3118680.
• The calling of any method will lead to the warning.

Description of Your Machine

Google Chrome Version 71.0.3578.98 (Official Build) (64-bit) macOS 10.13.6

Console Logs / Screenshots

MacBook-Pro-Viktor:~ viktor$ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' https://core-fullnode.poa.network/
{"jsonrpc":"2.0","result":"Parity-Ethereum//v2.2.1-beta-5c56fc5-20181114/x86_64-linux-gnu/rustc1.30.1","id":67}

[tayvano]

Thanks so much for the report. For some reason we are sending this call out with the param pending instead of latest. We're checking into why we did this in the first place to ensure we don't inadvertently break something else when implementing the fix for this issue.

[tayvano]

Just an update on our end

The Infura POA node is working with the current parameters we are giving. We're thinking that it might be related to how your node is configured and/or related to this issue https://github.com/paritytech/parity-ethereum/issues/9707?

The weird thing is that all of our other nodes across chains are working properly with the parameters we're currently using so we're thinking this could be more easily resolved by adjusting your node settings. What exactly those settings are is beyond my paygrade unfortunately.

[blurpesec]

To provide additional insight: Both your's and Infura's nodes work with the "Latest" parameter for eth_call JSON RPC requests. Infura's node still works with "pending", but yours does not. I used Postman to test these.

EDIT: Infura team mentioned that they had an issue a few weeks ago that they haven't been able to replicate where when using both a config toml file and cmd-line args, one cancelled the other out, forcing the node to not be run as archive. Maybe check that you're not doing this :-)

[tayvano]

Hey @vbaranov—just wondering if you had any luck solving this on your end?

[vbaranov]

@tayvano thank you and @blurpesec for the ideas. Tried different configurations for Parity full archive node - none of them was successful. Also, we have no mixing toml config and CLI parameters. Actually, I opened an issue on Parity end https://github.com/paritytech/parity-ethereum/issues/10096 . Anyways, I guess this issue is related rather to Parity Ethereum client configuration, then to MyCrypto. Thus, this issue can be closed. I am just curious if you could point me out to why you are using pending state by default instead of latest.

[tayvano]

@vbaranov We never did fully determined why we decided to use the pending state across the calls instead of latest. We did confirm that using latest breaks things for some reason (this is actually even more confusing to me than the "why use pending" question.)

I'll leave this open for now so that I can check in occasionally and stay abreast of any updates on Parity's end or changes we need to make.

[vbaranov]

@tayvano

UPDATE: as far as I can see, Infura updated their client to Parity-Ethereum//v2.2.6-beta-e9396e1-20190109/x86_64-linux-gnu/rustc1.31.1:

MacBook-Pro-Viktor:~ viktor$ curl -X POST \
> -H 'Content-Type: application/json' \
> --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":42}' \
> https://poa.infura.io
{"jsonrpc":"2.0","id":42,"result":"Parity-Ethereum//v2.2.6-beta-e9396e1-20190109/x86_64-linux-gnu/rustc1.31.1"}

And the problem from this issue is also reproducible now with default POA Core RPC endpoint https://poa.infura.io

MacBook-Pro-Viktor:~ viktor$ curl -X POST \
> --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"to": "0x4316f704989157162de90997ce1a05cff3118680", "data": "0x8da5cb5b"}, "pending"],"id":42}' \
> https://poa.infura.io
{"jsonrpc":"2.0","id":42,"error":{"code":-32000,"message":"This request is not supported because your node is running with state pruning. Run with --pruning=archive."}}

And it is not in a syncing state:

MacBook-Pro-Viktor:~ viktor$ curl -X POST \
> --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
> https://poa.infura.io
{"jsonrpc":"2.0","id":1,"result":false}

Thus, users are not able to interact with POA core through MyCrypto.

[zulhfreelancer]

Hi MyCrypto team, any update on this issue?

Update

I just tested MEW v3.39.0 and it doesn't produce "This request is not supported because your node is running with state pruning. Run with --pruning=archive." error. I can read and write states without any issues.

[tayvano]

Let me check for you.

The new MyCrypto that were working on is on the /gau branch and we are using ethers.js, which will likely resolve this issue.

[zulhfreelancer]

Thanks @tayvano

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.