Problem with Parity 2.7.2 service

[adradr]

Hey guys!

I've got the following error when starting up the services. The problem is Failed to auto-update latest ETH price: Hyper(Error { kind: Connect, cause: Custom { kind: Other, error: Custom { kind: InvalidData, error: WebPKIError(UnknownIssuer) } } })",

I am using an Ubuntu 18.04.3 LTS instance on AWS as the installation suggests.

Full output of check_rpc_status:

TASK [check_rpc_status : debug] ************************************************************************************************************************************************************************************************************** ok: [18.194.14.118] => { "parity_mainnet_logs.stdout_lines": [ "Attaching to resources-docker-stack_parity_mainnet_1", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:53 UTC Starting Parity-Ethereum/v2.7.2-stable-2662d19-20200206/x86_64-unknown-linux-gnu/rustc1.41.0", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:53 UTC Keys path /data/keys/ethereum", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:53 UTC DB path /data/chains/ethereum/db/906a34e69aec8c0d", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:53 UTC State DB configuration: fast", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:53 UTC Operating mode: active", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:53 UTC Configured for Ethereum using Ethash engine", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:53 UTC Running without a persistent transaction queue.", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:53 UTC Failed to auto-update latest ETH price: Hyper(Error { kind: Connect, cause: Custom { kind: Other, error: Custom { kind: InvalidData, error: WebPKIError(UnknownIssuer) } } })", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:33:59 UTC Public node URL: enode://6fa552913b0516a434c7b3455962c92c32b9551046ff6c7610b390981da85206f22eb2baf0bde4756e4c9f641912a1b27427f441b8ca01a2bd3d4371995134e7@192.168.144.3:30303", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:34:28 UTC 0/16 peers 920 bytes chain 3 MiB db 0 bytes queue 1 KiB sync RPC: 0 conn, 0 req/s, 0 µs", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:34:53 UTC Syncing #0 0xd4e5…8fa3 0.00 blk/s 0.0 tx/s 0.0 Mgas/s 0+ 0 Qed #0 1/16 peers 920 bytes chain 3 MiB db 0 bytes queue 2 KiB sync RPC: 0 conn, 1 req/s, 19 µs", "\u001b[36mparity_mainnet_1 |\u001b[0m 2020-08-24 20:34:58 UTC Syncing #0 0xd4e5…8fa3 0.00 blk/s 0.0 tx/s 0.0 Mgas/s 0+ 0 Qed #0 1/16 peers 920 bytes chain 3 MiB db 0 bytes queue 2 KiB sync RPC: 0 conn, 2 req/s, 19 µs",

[adradr]

Sorry, false alarm, it started sync finally!

[adradr]

Update: this parity-2.7.2 service is still in sync, but it seems weird. I have attached an image showing docker logs, but the order of blocks is not correct, there are multiple skipped block, and also its way slower than the parity-2.5.13, which already synced since last night.

[GrzegorzMatuszakTSH]

As we discussed on slack:

We wanted to use 2.7 but it was too buggy, so we downgraded our parities to 2.5 with hope that they will fix most of bugs.
Finally, parity contributors agreed that parity with higher version than 2.5 is not stable and they decided to start again from version 2.5.
Also, they recommended to use 2.5 for now.

The worst thing is that there is a difference in database structure between 2.5 and 2.7. It's not possible to downgrade versions using the same db.

Currently, they don't have solution for that.
There are three possibilities for now:

• Wait for version 3.1 which might have possibility to migrate from 2.7 to 3.1 (with they speed reaction we will wait months for that)
• Use 2.7 (or 3.0) which is not supported and fix errors manually (e.g. cron which restart parity each hours)
• Migrate to 2.5 version (it will require to sync whole db again)

Sources:

• https://medium.com/openethereum/vision-for-openethereum-ex-parity-client-eb7b11f6eef8
• https://github.com/openethereum/openethereum/issues/11858