Issue Summary

Bamboo DC warm standby: Expiry schedule changes on primary node are not propagated to secondary node without restart

Steps to Reproduce

1. Set up a Bamboo DC (v12.1.2) warm standby cluster with 2 nodes (1 primary, 1 secondary)
2. Configure global build expiry with a specific cron schedule (e.g. 0 0 0 ? * * — daily at midnight)
3. Confirm both nodes are visible under Administration → Overview → Cluster
4. On the primary node, update the expiry cron schedule to a new value (e.g. 0 0/2 * ? * * — every 2 minutes)
5. Observe expiry job execution on the secondary node 

Expected Results

The secondary node should pick up the updated expiry schedule via cluster event sync (gRPC) or DB read without requiring a restart. Since expiry configuration is stored in the database and the warm standby architecture is designed to keep nodes in sync, config changes should propagate automatically.

Actual Results

The secondary node continues running expiry based on the previous schedule. The new cron schedule is only picked up after restarting the secondary node.

When updating the expiry schedule, the following log gets printed from the secondary node:

2026-04-27 19:24:39,903 INFO [AtlassianEvent::0-BAM::EVENTS:pool-1-thread-43] [RemoteBroadcastEventListener] Event broadcast not yet active, event: com.atlassian.bamboo.event.AdministrationConfigurationUpdatedEvent@7c83ee3d 

Workaround

Restart the secondary (warm standby) node after changing expiry settings on the primary.