@checkstack/backend 0.8.0 → 0.8.1

package/CHANGELOG.md

@@ -1,5 +1,34 @@
 # @checkstack/backend
 
+## 0.8.1
+
+### Patch Changes
+
+- 2a749d3: fix: run afterPluginsReady in topological order; merge daily rollups on conflict
+
+  Two resilience fixes for the dependency chain:
+
+  1. **Plugin loader**: Phase 3 (`afterPluginsReady`) now iterates plugins
+     in the same topologically-sorted order as Phase 2 (`init`). Previously
+     it iterated `pendingInits` in registration order, which raced
+     subscription-spec dependencies — catalog's afterPluginsReady registers
+     `catalog.system` and `catalog.group` notification targets, and emitting
+     plugins (incident, maintenance, …) call `registerSubscriptionSpec`
+     against those targets in their own afterPluginsReady. With registration
+     order, an emitter could run before catalog and hit
+     `Target type catalog.group is not registered`. Sorted order encodes
+     the dependency via `spec.target.ownerPlugin`, so the emitter now
+     always runs after the target owner.
+
+  2. **Healthcheck retention job**: the daily rollup now upserts
+     `health_check_aggregates` with `ON CONFLICT DO UPDATE` instead of a
+     plain insert. Previously, late-arriving hourly aggregates (e.g. from
+     a satellite that was offline when the prior rollup ran) would crash
+     the rollup with a unique-constraint violation on
+     `(configuration_id, system_id, bucket_start, bucket_size, source_id)`.
+     The merge sums counts and folds min/max/p95 into the existing daily
+     row.
+
 ## 0.8.0
 
 ### Minor Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/backend",
-  "version": "0.8.0",
+  "version": "0.8.1",
   "checkstack": {
     "type": "backend"
   },

package/src/plugin-manager/plugin-loader.ts

@@ -515,7 +515,15 @@ export async function loadPlugins({
       );
     }
   }
-  for (const p of pendingInits) {
+  // Run afterPluginsReady in topologically-sorted order, matching Phase
+  // 2 init order. Iterating `pendingInits` directly would use registration
+  // order, which races dependency chains: e.g. catalog's
+  // afterPluginsReady registers `catalog.group` as a notification target,
+  // and emitting plugins' afterPluginsReady call `registerSubscriptionSpec`
+  // against it — so the emitters MUST run after catalog. Topo order
+  // already encodes this dependency (via spec.target.ownerPlugin).
+  for (const id of sortedIds) {
+    const p = pendingInits.find((x) => x.metadata.pluginId === id)!;
     if (p.afterPluginsReady) {
       try {
         const resolvedDeps: Record<string, unknown> = {};