Issue Summary

On a Data Center node, Jira's application-property store (the propertyentry table, holding keys such as jira.setup, jira.sid, and plugin upgrade-task history) can be silently wiped during startup.

The property-store implementation is selected once, lazily, on first use. If that first use happens on an early request thread before the DatabaseConfigurationManager component is resolved, the node selects the in-memory implementation (MemorySwitchToDatabaseBackedPropertiesManager) instead of the DB-backed one. When the database is activated moments later, the node performs a memory->DB "switch" that is destructive: it clears the destination (the shared DB property store) and repopulates it from the near-empty in-memory set.

Because the selection falls back silently, a fully-configured node (valid dbconfig.xml, working DB) can wipe the shared property store with no error logged.

This is a regression introduced by the fix for the startup race in BootstrapContainerRegistrar shipped in Jira 9.15.0. That change significantly reduced the frequency of the underlying race but converted the failure mode from "Jira fails to start with a clear error" (previously requireNonNull(getComponentInstance(...)) threw) to "Jira silently selects the destructive in-memory manager and wipes the property store" (now Optional.ofNullable(getComponent(...)).orElse(MemorySwitch...)).

Steps to Reproduce

This is an extremely rare startup race condition and is near-impossible to reproduce reliably without a debugger to force the thread interleaving. In principle:

1. Run a Jira Data Center node with a valid, already-configured database.
2. Arrange for a request thread to access the property store before the DatabaseConfigurationManager component is resolved during startup (e.g. a load balancer / health check sending traffic very early in boot).
3. With that interleaving, the node selects the in-memory property manager and, once the database activates, performs the destructive memory->DB switch.

To force it deterministically, use a debugger to hold the startup thread so that a property read on another thread occurs before database activation completes.

Expected Results

The node uses the database-backed property store, or - if the property store is genuinely accessed before the database is available on a configured node - startup fails with a clear error rather than proceeding. The existing shared propertyentry data is never modified as a side effect of startup.

Actual Results

The node selects the in-memory property store, then performs a destructive memory->DB switch that deletes the existing shared application properties. The switch is logged; the selection of in-memory mode is not:

[c.a.j.config.properties.MemorySwitchToDatabaseBackedPropertiesManager] Switching from in-memory property set to database property set.

Downstream symptoms - all consequences of the wipe:

• Server ID changes (and on a cluster, different nodes can generate different IDs, causing NonUniqueResultException on server-ID lookups).
• Jira thinks it is not set up ("Jira not setup yet"), exposing the Setup Wizard.
• Plugin / ActiveObjects upgrade tasks re-run (recorded model versions are gone), failing against the already-migrated schema.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available.