2026.09.66 — 2026-09-30

Breaking

• Put every store that grows with use under one retention policy (d78d8298)

  Metrics, message index, broker events, request-reply flows, captured payloads, audit events, bulk runs, transfer runs, alert history, broker configuration history, setup findings, classification findings, expired sessions and storage samples are each a store with a bounded retention, purged in batches by the installation-wide housekeeping job. Audit events are kept forever unless a retention is set. A message-index subscription can keep data no longer than the message index store. Only open classification findings expire; confirmed and dismissed ones stay. Spring Session's own per-instance cleanup is off.

• Add the data lifecycle engine and the HousekeepingContributor plugin API (71e600b2)

  A new installation-wide housekeeping job purges every registered store to its retention in bounded batches and records one PURGE_STORE audit event per store. Plugins contribute stores through the new HousekeepingContributor API.

  Settings can declare bounds: a value outside them is rejected with the allowed range. SettingsService.addPluginSettings is replaced by addSettings(namespace, defs, writePermission).

Added

• Add the Data page for retention, quotas and storage health (fa9dc98d)

  Administration → Data lists every store with its retention, rows, size, quota and last purge. Select a store to change its retention, quota and warning threshold, and preview how much the next purge would remove before saving. The Storage health view lists every table with its size, seven-day growth, dead tuples, last vacuum and upcoming partitions, unhealthy tables first. Viewing needs data:read and changing a policy needs data:write.

  The plugin template keeps its notes under the lifecycle through a HousekeepingContributor instead of its own pruning job, and builds against contract 5. LifecycleSql is part of the plugin API.

• Alert on storage quotas and table health, once per installation (13613715)

  Alert rules can now be about the installation rather than a cluster. Two such rules are created on upgrade: Storage quota fires when a store passes its quota warning, and Storage health fires when a table is bloated, is not vacuumed, or is missing an upcoming daily partition. They are ordinary rules: route them to a channel, edit or disable them from any cluster's alerts view, where they carry an Installation badge. Only a global alert grant sees or changes them.

• Put every store that grows with use under one retention policy (d78d8298)

  Metrics, message index, broker events, request-reply flows, captured payloads, audit events, bulk runs, transfer runs, alert history, broker configuration history, setup findings, classification findings, expired sessions and storage samples are each a store with a bounded retention, purged in batches by the installation-wide housekeeping job. Audit events are kept forever unless a retention is set. A message-index subscription can keep data no longer than the message index store. Only open classification findings expire; confirmed and dismissed ones stay. Spring Session's own per-instance cleanup is off.

• Report storage health per table and sample table sizes for growth (7d4b8439)

  The new storage health read (GET /api/v1/data/health) reports each table's size, seven-day growth, dead tuples, last vacuum and missing daily partitions. An installation-wide storage-sample job records table sizes; the samples are kept by the new storage-samples store.

• Add the data lifecycle engine and the HousekeepingContributor plugin API (71e600b2)

  A new installation-wide housekeeping job purges every registered store to its retention in bounded batches and records one PURGE_STORE audit event per store. Plugins contribute stores through the new HousekeepingContributor API.

  Settings can declare bounds: a value outside them is rejected with the allowed range. SettingsService.addPluginSettings is replaced by addSettings(namespace, defs, writePermission).

Fixed

• Apply a plugin setting's stored value as soon as the plugin activates (a3fa3121)

  A plugin's setting that an operator had changed used to fall back to its default after the plugin was activated again, until the next change to any setting. Activation now reads the stored values of the plugin's own settings and applies only those, without re-applying Studio's other settings.