Feature flags and Khepri metadata not persisting across Docker container restarts

[skry-dev]

Describe the bug

Description:
Environment:
RabbitMQ Version: 4.2.5
Erlang Version: 27.3.4.10
Docker Image: rabbitmq:4.2.5-management
OS: Linux (Docker environment)

The Issue:
Every time the RabbitMQ container is restarted, all feature flags (including khepri_db) revert to a disabled state. Consequently, the metadata store reverts to mnesia even though a successful migration to khepri was logged before the restart. It seems like the node treats every restart as a "virgin boot."

Reproduction steps

1. Cluster Setup: Deploy a 3-node RabbitMQ cluster using version 4.2.5 on Docker.
2. Feature Flags: Enable all available feature flags (including khepri_db) across the entire cluster using rabbitmqctl enable_feature_flag all.
3. Resource Creation: Create a new Virtual Host (e.g., /test) and a Quorum Queue within that vhost.
4. Node Restart: Perform a standard docker restart on one of the nodes (e.g., rabbit@node2).
5. Observation (Vhost): Once the node is back up, it fails to sync correctly. The Management UI shows that the /test virtual host is in a partial state (Inaccessible/Error). And cluster is unstable.

Observation (Metadata Store): * Running rabbitmq-diagnostics metadata_store_status on the restarted node returns mnesia.
Running the same command on the other nodes returns the correct Raft/Khepri status.

Observation (UI): The Management UI displays a warning prompt suggesting that "Feature flags need to be enabled," even though they were enabled globally before the restart.

I added logs and screenshots.

rabbit.log

Expected behavior

The node should recognize the existing metadata in the volume and start with Khepri and previously enabled feature flags active.

Thank you.

Additional context

No response

[mkuratczyk]

Almost certainly you just didn't configure a volume that would persist across restarts. If you believe you did - please provide all the YAML and commands used for us to reproduce.

[skry-dev]

rabbit-config.txt
docker-compose.yml

I am upgrade 4.1.5 to 4.2.5. Should I change the file path of volumed data directory?

[mkuratczyk]

Please provide the exact steps you are performing. Most likely the problem is somewhere in those steps.
And if there's an actual issue in RabbitMQ - we also need these steps, because if what you described was a universal problem, every RabbitMQ upgrade/restart would fail and we are fairly confident that's not the case.

[skry-dev]

I changed volume path and it fixed:

old: /rabbit/volumes/data:/var/lib/rabbitmq/mnesia/cluster-rabbit@node1

new: /rabbit/volumes/data:/var/lib/rabbitmq/mnesia

Thank you.