Expected Behavior
The persistence health check (GET /rest/persistence/health, Settings → Health in the UI) should not report a problem for a configuration that works as documented.
Current Behavior
Any configuration entry whose only strategy is restoreOnStartup is reported as PERSISTENCE_SERVICE_ITEMS_NO_STORE_STRATEGY, regardless of the rest of the configuration. The check looks at each entry in isolation:
} else if (strategies.size() == 1
&& PersistenceStrategy.Globals.RESTORE.equals(strategies.getFirst())) {
persistenceProblems.add(new PersistenceServiceProblem(
PersistenceServiceProblem.PERSISTENCE_NO_STORE_STRATEGY, serviceId, items, editable));
}That makes the very common split configuration permanently red, although it is correct:
items: ["*"], strategies: ["everyChange"] <- stores everything
items: ["gRestoreOnStartup*"], strategies: ["restoreOnStartup"] <- adds restore for a group
The items in that group are stored — by the first entry. Persistence application is additive: PersistenceManagerImpl.storeItem() streams over all matching configurations and stores for each, without any first-match-wins or override.
This is not an undocumented implementation detail. configuration/persistence.md states it explicitly:
The entries are additive. This means if one Item appears in more than one <itemlist> either directly or indirectly (e.g. * which includes all Items or as a member of a Group used in <groupName>*), all the strategies […] listed on all those lines apply to that Item.
So the health check currently contradicts the documented semantics of the very configuration format it is checking, and it does so with a factual claim — "these items have no store strategy" — that is false for the configuration above.
Reported on a 5.2.1 installation whose gRestoreOnStartup members carry several thousand datapoints per 48 hours in InfluxDB while the health page insists they have no store strategy.
Possible Solution
Only report the problem when no other entry of the same service both has a store strategy and provably covers the same items. Staying conservative matters more than being clever here: suppressing a warning that should fire means silently losing data, so anything that cannot be proven covered should keep warning. A PR follows.
Your Environment
Expected Behavior
The persistence health check (
GET /rest/persistence/health, Settings → Health in the UI) should not report a problem for a configuration that works as documented.Current Behavior
Any configuration entry whose only strategy is
restoreOnStartupis reported asPERSISTENCE_SERVICE_ITEMS_NO_STORE_STRATEGY, regardless of the rest of the configuration. The check looks at each entry in isolation:That makes the very common split configuration permanently red, although it is correct:
The items in that group are stored — by the first entry. Persistence application is additive:
PersistenceManagerImpl.storeItem()streams over all matching configurations and stores for each, without any first-match-wins or override.This is not an undocumented implementation detail.
configuration/persistence.mdstates it explicitly:So the health check currently contradicts the documented semantics of the very configuration format it is checking, and it does so with a factual claim — "these items have no store strategy" — that is false for the configuration above.
Reported on a 5.2.1 installation whose
gRestoreOnStartupmembers carry several thousand datapoints per 48 hours in InfluxDB while the health page insists they have no store strategy.Possible Solution
Only report the problem when no other entry of the same service both has a store strategy and provably covers the same items. Staying conservative matters more than being clever here: suppressing a warning that should fire means silently losing data, so anything that cannot be proven covered should keep warning. A PR follows.
Your Environment
mainsourcesmain