@checkstack/healthcheck-common 0.13.0 → 1.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,144 @@
1
1
  # @checkstack/healthcheck-common
2
2
 
3
+ ## 1.0.1
4
+
5
+ ### Patch Changes
6
+
7
+ - Updated dependencies [50e5f5f]
8
+ - @checkstack/catalog-common@2.0.1
9
+ - @checkstack/common@0.8.0
10
+ - @checkstack/notification-common@1.0.1
11
+ - @checkstack/signal-common@0.2.1
12
+
13
+ ## 1.0.0
14
+
15
+ ### Major Changes
16
+
17
+ - 32d52c6: feat: notification target pattern + per-spec subscriptions
18
+
19
+ Replaces the all-or-nothing catalog system/group notification model with a
20
+ platform-level target pattern. Each notification-emitting plugin declares
21
+ _subscription specs_ against typed _target_ objects exported from the
22
+ target's owning plugin (catalog ships `catalogSystemTarget` and
23
+ `catalogGroupTarget`). Notification-backend handles every per-resource
24
+ group lifecycle, parent-edge inheritance, and legacy-subscription seeding
25
+ — plugins never author groupId helpers, lifecycle hooks, or migration
26
+ code again.
27
+
28
+ **Plugin-author surface area is now ~12 lines per emitter:**
29
+
30
+ ```ts
31
+ // <plugin>-common
32
+ const { defineSubscription } = createSubscriptionFactory(pluginMetadata);
33
+ export const fooSystemSubscription = defineSubscription({
34
+ localId: "system",
35
+ target: catalogSystemTarget,
36
+ display: { title: "Foo Alerts", description: "...", iconName: "Bell" },
37
+ });
38
+
39
+ // <plugin>-backend register()
40
+ env.registerSubscriptionSpecs([fooSystemSubscription]);
41
+ // ^ feeds the plugin loader's dependency sorter — each spec's
42
+ // target.ownerPlugin becomes an implicit init-order dep, so this
43
+ // plugin automatically waits for catalog (the target owner) to
44
+ // finish init + afterPluginsReady before its own runs.
45
+
46
+ // <plugin>-backend afterPluginsReady
47
+ await notificationClient.registerSubscriptionSpec(
48
+ specToRegistration(fooSystemSubscription)
49
+ );
50
+ // dispatch
51
+ await notificationClient.notifyForSubscription({
52
+ specId: fooSystemSubscription.specId,
53
+ resourceKeys: [systemId],
54
+ title,
55
+ body,
56
+ importance,
57
+ action,
58
+ collapseKey,
59
+ subjects,
60
+ });
61
+
62
+ // <plugin>-frontend
63
+ createNotificationSubscriptionExtension({ spec: fooSystemSubscription });
64
+ ```
65
+
66
+ **Migrated plugins**: anomaly, incident, maintenance, healthcheck,
67
+ dependency. Each lost its bespoke `notification-groups.ts`,
68
+ `bootstrap*NotificationGroups`, `ensure*Group`, and inheritance walk —
69
+ all of that is now centralized in notification-backend's
70
+ `subscription-engine`.
71
+
72
+ **Plugin loader change** (`@checkstack/backend-api`,
73
+ `@checkstack/backend`): the register-time API gains
74
+ `env.registerSubscriptionSpecs([...specs])`. The dependency sorter
75
+ walks `spec.target.ownerPlugin` for every declared spec and adds the
76
+ target owner as an init-order dependency of the emitting plugin. This
77
+ guarantees that catalog (the owner of the platform's `system` and
78
+ `group` targets) completes init + afterPluginsReady before any
79
+ emitting plugin tries to register its specs against the notification
80
+ service — no string-prefix heuristics, no manual `dependsOnPlugins`
81
+ list, no stub rows. Plugins that fail to declare their specs at
82
+ register time get a clear `Target type X is not registered. Did the
83
+ emitting plugin declare this spec via env.registerSubscriptionSpecs?`
84
+ error from the dispatcher.
85
+
86
+ **Removed** (no backwards compat):
87
+
88
+ - `catalogClient.notifySystemSubscribers` and
89
+ `catalogClient.notifyManySystemSubscribers`
90
+ - `notificationClient.notifyUsers` and `notificationClient.notifyGroups`
91
+ as direct dispatch primitives — replaced by spec-bound
92
+ `notifyForSubscription`
93
+ - catalog's `bootstrapNotificationGroups` (replaced by
94
+ `bootstrapNotificationTargets`)
95
+
96
+ **Enforcement**: the dispatcher rejects calls referencing unregistered
97
+ specIds, specs owned by other plugins, or resourceKeys that haven't been
98
+ pushed via `upsertNotificationResource`. Display metadata for any
99
+ groupId is recoverable via the spec registry, so audit lists render
100
+ correct labels even when an emitter's frontend isn't loaded.
101
+
102
+ **Per-field anomaly mute** keeps working — it now lives inside the
103
+ generic SubscriptionRow's optional `SubControls` panel
104
+ (`AnomalyFieldMuteList`), exposed through the catalog system detail
105
+ page's notifications card.
106
+
107
+ The catalog system detail page renders a "Notifications" card hosting
108
+ `SystemNotificationSubscriptionsSlot`. The matching group surface is
109
+ not yet rendered — group-level subscriptions are wired end-to-end on
110
+ the backend; a follow-up will add the host UI.
111
+
112
+ **Migration of existing subscribers**: target types declare a
113
+ `legacyGroupIdTemplate`; on first registration of each spec,
114
+ notification-backend reads subscribers from the legacy
115
+ `catalog.system.<id>` / `catalog.group.<id>` groups and seeds the new
116
+ spec groups exactly once per (spec × resource) pair, tracked in
117
+ `subscription_migrations`. Anomaly stays opt-in (its target also
118
+ declares the template, but the user-explicit nature of the original
119
+ opt-in flow means the seeding produces the same set of subscribers
120
+ they already had).
121
+
122
+ ### Minor Changes
123
+
124
+ - 32d52c6: Bulk notifications affecting multiple systems and collapse lifecycle events into a single card.
125
+
126
+ Notifications now carry an optional `subjects` array (the entities they affect) and an optional `collapseKey` (so related notifications collapse into one row per recipient). Incidents, maintenances, anomalies, healthchecks, and dependency-impact events route through these new fields, so an incident affecting three systems produces one in-app notification + one external send per subscriber instead of three. Lifecycle updates for the same entity (created → updated → resolved) also collapse, with an expandable "+N updates" timeline.
127
+
128
+ Subject kinds are namespaced as `<pluginId>.<localKind>` and built via type-safe helpers exported from each domain's common package (`createSystemSubject`, `incidentCollapseKey`, etc.). The frontend kind registry (`registerSubjectKind`) lets plugins bind icon + label for their kinds; unknown kinds fall back to a generic chip.
129
+
130
+ All notification strategies (SMTP, Slack, Discord, Teams, Telegram, Pushover, Gotify, Webex, Backstage) render the affected subjects natively in their format (HTML cards, Slack blocks, Discord embed fields, adaptive cards, markdown lists, etc.).
131
+
132
+ ### Patch Changes
133
+
134
+ - Updated dependencies [32d52c6]
135
+ - Updated dependencies [32d52c6]
136
+ - Updated dependencies [32d52c6]
137
+ - Updated dependencies [32d52c6]
138
+ - Updated dependencies [32d52c6]
139
+ - @checkstack/notification-common@1.0.0
140
+ - @checkstack/catalog-common@2.0.0
141
+
3
142
  ## 0.13.0
4
143
 
5
144
  ### Minor Changes
package/package.json CHANGED
@@ -1,6 +1,7 @@
1
1
  {
2
2
  "name": "@checkstack/healthcheck-common",
3
- "version": "0.13.0",
3
+ "version": "1.0.1",
4
+ "license": "Elastic-2.0",
4
5
  "type": "module",
5
6
  "exports": {
6
7
  ".": {
@@ -9,16 +10,18 @@
9
10
  },
10
11
  "dependencies": {
11
12
  "@checkstack/common": "0.7.0",
12
- "@checkstack/signal-common": "0.1.10",
13
+ "@checkstack/catalog-common": "2.0.0",
14
+ "@checkstack/notification-common": "1.0.0",
15
+ "@checkstack/signal-common": "0.2.0",
13
16
  "zod": "^4.2.1"
14
17
  },
15
18
  "devDependencies": {
16
19
  "typescript": "^5.7.2",
17
- "@checkstack/tsconfig": "0.0.5",
20
+ "@checkstack/tsconfig": "0.0.6",
18
21
  "@checkstack/scripts": "0.1.2"
19
22
  },
20
23
  "scripts": {
21
- "typecheck": "tsc --noEmit",
24
+ "typecheck": "tsgo -b",
22
25
  "lint": "bun run lint:code",
23
26
  "lint:code": "eslint . --max-warnings 0"
24
27
  },
package/src/index.ts CHANGED
@@ -41,6 +41,7 @@ export interface HealthCheckConfiguration {
41
41
 
42
42
  export * from "./rpc-contract";
43
43
  export * from "./plugin-metadata";
44
+ export * from "./notifications";
44
45
  export { healthcheckRoutes } from "./routes";
45
46
 
46
47
  // =============================================================================
@@ -0,0 +1,42 @@
1
+ import {
2
+ createCollapseKeyBuilder,
3
+ createSubscriptionFactory,
4
+ } from "@checkstack/notification-common";
5
+ import {
6
+ catalogSystemTarget,
7
+ catalogGroupTarget,
8
+ } from "@checkstack/catalog-common";
9
+ import { pluginMetadata } from "./plugin-metadata";
10
+
11
+ /**
12
+ * Collapse key for system-health transition notifications driven by health
13
+ * checks. Frontend merges health-state changes (degraded → unhealthy →
14
+ * healthy) for the same system into a single card.
15
+ */
16
+ export const systemHealthCollapseKey = createCollapseKeyBuilder(
17
+ pluginMetadata,
18
+ "system-health",
19
+ );
20
+
21
+ const { defineSubscription } = createSubscriptionFactory(pluginMetadata);
22
+
23
+ export const healthcheckSystemSubscription = defineSubscription({
24
+ localId: "system",
25
+ target: catalogSystemTarget,
26
+ display: {
27
+ title: "Health Status",
28
+ description:
29
+ "Healthy / degraded / unhealthy transitions detected by health checks for this system.",
30
+ iconName: "Heart",
31
+ },
32
+ });
33
+
34
+ export const healthcheckGroupSubscription = defineSubscription({
35
+ localId: "group",
36
+ target: catalogGroupTarget,
37
+ display: {
38
+ title: "Health Status",
39
+ description: "Health-status transitions for any system in this group.",
40
+ iconName: "Heart",
41
+ },
42
+ });
package/tsconfig.json CHANGED
@@ -2,5 +2,19 @@
2
2
  "extends": "@checkstack/tsconfig/common.json",
3
3
  "include": [
4
4
  "src"
5
+ ],
6
+ "references": [
7
+ {
8
+ "path": "../catalog-common"
9
+ },
10
+ {
11
+ "path": "../common"
12
+ },
13
+ {
14
+ "path": "../notification-common"
15
+ },
16
+ {
17
+ "path": "../signal-common"
18
+ }
5
19
  ]
6
- }
20
+ }