Panic at Option::unwrap() on a None value in parity-db during Cloud Migration with Polkadot v1.12.0

[MrWhiteHD]

Hello,

We encountered an issue with Polkadot v1.12.0 during our cloud migration process. The same image and Helm chart that functioned correctly on our previous cloud environment now results in the following error:

Thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/parity-db-0.4.12/src/file.rs:1301

Here are the details of our setup:

• Environment: Test (DEV)
• We do not operate Kusama, so we using main image - hence no keys are provided
• The setup worked flawlessly in our old cloud environment

We suspect there might be an incompatibility or misconfiguration triggered by the new cloud environment.

Could you please help us resolve this issue?

Thank you!

Best regards,
Jakub

[bkchr]

CC @arkpar @cheme

[cheme]

The error might be line 130 (not 1301), anyway only unwrap() calls in file.rs are related to memory map access.
https://github.com/paritytech/parity-db/blob/47b6c98455f8875b6eeb980d35a2be62f64d074f/src/file.rs#L98 probably returned None so here there may be an issue accessing a db file, don't know what is the issue but would check files in parity db are present, user rights correct, accessible from polkdot process and others range of possible file accesses issues.

[MrWhiteHD]

Thank you for the tips. We're using the image to start the full node, and in the old cloud environment, the DEV runs without issues. However, after the migration with the same code, the full node fails to start due to an error.

I've already tried adjusting permissions on the pod and checked that all data is present, but the error seems to be coming from somewhere else.

[arkpar]

@MattHalpinParity Could you take a look at this?
First of all, the error should be handled and propagated. Then we need to figure out what's causing it. Could be the OS configuration that limits the address space for memory maps.

[MattHalpinParity]

Sure, I'll sort out the error handling.
Is there any way to repro the issue?

[MrWhiteHD]

The thread can be closed; we have identified and resolved the issue by discontinuing the use of the snapshot function, which was temporarily implemented due to the unavailability of warp-sync. We have reverted to using warp-sync, and our Polkadot containers have started without issues and remained stable since then. The error message was misleading for us, which led us to investigate and search for the problem in other areas initially.

[bkchr]

First of all, the error should be handled and propagated.

We should still do this.

[MattHalpinParity]

First of all, the error should be handled and propagated.

We should still do this.

Yup, I'll still make the changes.