2026.09.44 — 2026-09-27

Added

• Plugins publish metrics that Studio charts, exports and alerts on (d74858fe)

  A plugin can now publish its own metrics through Studio instead of keeping a store of its own. It declares each metric in plugin.json (name, description, unit, subject, and the permission that reads it) and answers for it with a PluginMetricSource bean. On every tier-B scrape Studio samples each running plugin's sources and:

  • stores the values in its time series, with the same retention as queue metrics;
  • exposes them on /actuator/prometheus as studio_plugin_metric{plugin, metric, cluster, subject};
  • lets threshold alert rules watch them, with the usual comparators, durations and channels. A rule's scope can narrow it to some subjects with subjectPattern.

  A plugin can also declare default alert rules. They are created once on every cluster, when the plugin first runs and on clusters registered later; editing or deleting one is never undone. While the plugin is not running, rules on its metrics do not fire, and the rule list says their source is unavailable. The alert rule form lists the metrics of running plugins.

  GET /api/v1/clusters/{id}/metrics/plugin returns a plugin metric's series; it needs the permission the metric declares. The plugin SDK exports MetricChart and usePluginSeries, so a plugin draws Studio's own time-proportional chart. A source that fails or takes longer than two seconds is skipped for that scrape without delaying anything else.

  The plugin template publishes an example metric and rule, and the plugin guide has a "Metrics and alerts" section. The change is additive: plugins built for this contract version keep working.

Fixed

• Clear a closing dialog's timer when the action host unmounts (40f6e73e)

  A row action's dialog is removed a moment after it closes. If the page holding it went away in that moment, the pending timer still updated state afterwards; in the test run this surfaced as an unhandled "window is not defined" after the suite finished. The timers are now cleared on unmount.

• Run the demo's client applications with a small heap (72c0dc4d)

  The demo starts about a dozen long-lived producers and consumers inside the broker containers, one JVM each, and they took the broker's heap setting. Together they used more than 2 GB, which does not fit in a laptop's Docker VM next to Studio and six brokers. Each client now runs with a 64 MB heap and the serial collector, which is plenty for a few hundred small messages a second.

• Bound the brokers' and Studio's heap in the dev and demo stacks (aa16dc16)

  The dev and demo compose stacks left every broker at the image's 2 GB default heap and Studio without a fixed heap. Seven JVMs plus Postgres did not fit in a laptop's Docker VM (Docker Desktop's is often 4 to 8 GB), so under traffic the VM's OOM killer ended one of them: Studio restarted mid-request, and a client saw an empty reply. Each broker now runs with -Xmx512m and Studio with -Xmx1g, so the whole stack fits.