@checkstack/incident-backend 1.2.0 → 1.4.0
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 +242 -0
- package/package.json +18 -16
- package/src/automations.test.ts +523 -0
- package/src/automations.ts +601 -0
- package/src/hooks.ts +9 -45
- package/src/incident-entity.test.ts +266 -0
- package/src/incident-entity.ts +192 -0
- package/src/index.ts +110 -76
- package/src/router.ts +162 -98
- package/src/service.test.ts +199 -0
- package/src/service.ts +147 -3
- package/tsconfig.json +6 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,247 @@
|
|
|
1
1
|
# @checkstack/incident-backend
|
|
2
2
|
|
|
3
|
+
## 1.4.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- 270ef29: Replace the hardcoded auto-incident path with default automations (Wave 2 Phase 20).
|
|
8
|
+
|
|
9
|
+
BREAKING CHANGES: Auto-incident is now automation-driven. The hardcoded background path that opened incidents on sustained-unhealthy / flapping and closed them after a cooldown (`auto-incident.ts`, `auto-incident-close-job.ts`) is removed. On upgrade, an idempotent, threshold-preserving migration seeds equivalent default automations from each assignment's existing `NotificationPolicy`, so alerting behaviour is preserved 1:1:
|
|
10
|
+
|
|
11
|
+
- `sustainedUnhealthyTrigger.durationMinutes` -> the `for:` dwell on a `healthcheck.system_degraded` trigger -> `incident.create`.
|
|
12
|
+
- auto-close `autoCloseAfterMinutes` -> a `wait_until` (healthy continuously for the cooldown) -> `incident.resolve`.
|
|
13
|
+
- `useNotificationSuppression` -> the incident's `suppressNotifications`.
|
|
14
|
+
- `skipDuringMaintenance` -> a `{{ !health.system.in_maintenance }}` pre-run condition.
|
|
15
|
+
- `flappingTrigger.{transitions,windowMinutes}` -> a second automation on the `healthcheck.flapping_detected` trigger -> `incident.create`.
|
|
16
|
+
|
|
17
|
+
Auto-incidents remain ONE OPEN INCIDENT PER SYSTEM, faithful to the old behaviour. `incident.create` gains an opt-in `dedupe_open_for_system` config flag (default false, so existing/custom automations are unaffected): when true, it reuses an existing open incident on the target system instead of opening a duplicate (the old `findActiveAutoIncident(systemId)` semantic), returning the reused incident as the produced `incident` artifact. The seeded default automations set this flag, so a system with several failing checks - sustained and/or flapping - still gets a single open incident; whichever check crosses its threshold first opens it, and the rest dedupe to it. Both sustained and flapping default automations open at `critical` severity (parity with the old path). Per-system run dedup within an automation uses `concurrency_scope: "context_key"` + `mode: "single"`.
|
|
18
|
+
|
|
19
|
+
Operators can read, edit, disable, and extend these automations (see the "Customise auto-incident" guide). Seeded automations are tagged via `managedBy` (`auto-incident:<systemId>:<configurationId>:<kind>`) so the migration is a no-op on re-runs; anything unmappable is recorded as a migration-failure row.
|
|
20
|
+
|
|
21
|
+
Flapping DETECTION (transition recording + the `healthcheck.flapping_detected` emit) is relocated into `flapping-detector.ts` and survives; the emit now fires unconditionally on a threshold cross (no longer gated on `autoOpenIncidentOnUnhealthy`), matching the hook's documented intent and required for the flapping default automation. The legacy `health_check_auto_incidents` mapping table is no longer written or read (it will be dropped in a follow-up migration); `health_check_unhealthy_transitions` is retained for the flapping detector.
|
|
22
|
+
|
|
23
|
+
New service-typed `HealthCheckApi.listAutoIncidentPolicies` RPC exposes each assignment's effective notification policy for the migration. `incident.create` adds the `dedupe_open_for_system` flag (additive, defaults off).
|
|
24
|
+
|
|
25
|
+
- 270ef29: Add an `incident` artifact type to the incident automation actions (Phase 20 prerequisite).
|
|
26
|
+
|
|
27
|
+
Closes GAP 2 from the Phase 20 analysis - a single automation can now open an incident and reference it downstream (open then wait then resolve) without the operator repeating the id.
|
|
28
|
+
|
|
29
|
+
- New `incident` artifact type registered in incident-backend (`{ incidentId, status, severity, systemIds }`).
|
|
30
|
+
- `incident.create` now declares `produces: "incident"`, so the created incident is queryable in run scope (mirrors the Jira `produces: "jira.issue"` pattern).
|
|
31
|
+
- `incident.resolve` / `incident.add_update` / `incident.update_status` now declare `consumes: ["incident"]` and make their `incidentId` config optional, falling back to the upstream `incident` artifact (config takes priority, else artifact - the `resolveIssueKey` pattern). They fail with a clear error when neither is present.
|
|
32
|
+
|
|
33
|
+
- 270ef29: Fix several correctness defects around distributed coordination and stored-data handling.
|
|
34
|
+
|
|
35
|
+
- Dwell `for:` timers now fire via an atomic `DELETE ... RETURNING` claim, so two pods (or the stalled sweeper vs the queue consumer) can no longer both fire the same dwell.
|
|
36
|
+
- Postgres session-level advisory locks now keep connection affinity. A shared `AdvisoryLockService` (backed by a dedicated pooled client) replaces the previous acquire/release-on-different-connection pattern that leaked locks. Used by the script-packages installer election, the automation run resume + stalled sweeper, and (via a new transaction-scoped `withXactLock`) incident dedup.
|
|
37
|
+
- A storage migration that crashed mid-flight is now resumed on startup under the installer-election lock, instead of permanently wedging installs.
|
|
38
|
+
- Distributed script-package blobs carry a `blobSha256` and are verified before extraction (the SRI `integrity` hashes the npm tarball, not the transported archive). Backward-safe: entries without the field skip verification until a re-install regenerates the manifest.
|
|
39
|
+
- Archive extraction rejects zip-slip paths (absolute or `..` entries) before writing anything.
|
|
40
|
+
- `incident.create` with `dedupe_open_for_system` serializes its check-then-create per system, so concurrent triggers for the same system can't both open a duplicate incident.
|
|
41
|
+
- Seeded auto-incident filter expressions JSON-encode interpolated ids so a quote/backslash can't corrupt the expression.
|
|
42
|
+
- Stored jsonb snapshots (dwell `actorSnapshot`, wait-lock `waitConfig`) are validated with zod on load and degrade safely instead of flowing through as the wrong type.
|
|
43
|
+
|
|
44
|
+
- b995afb: Make incident automation actions fully reactive.
|
|
45
|
+
|
|
46
|
+
Only the `incident.create` action routed through the reactive `incident` entity; the `resolve`, `add_update`, and `update_status` actions called the incident service directly. Action-driven status flips therefore appended NO `entity_transitions` row, emitted NO `ENTITY_CHANGED` (so no `wait_until` woke), and fired NO `incident.resolved` / `.updated` derived trigger events — unlike the RPC router, which routes the same mutations through the entity handle.
|
|
47
|
+
|
|
48
|
+
The three actions now drive their writes through `writeIncidentEntity({ handle, incidentId, opts: { runId }, apply })` (re-reading the post-write state inside `apply` for the status-flipping actions), matching the router. As a result an action-driven resolve/status change now appends a transition, wakes suspended `wait_until` runs, and fires `incident.resolved` / `incident.updated`. The dispatch `runId` is passed so run-resolved secrets in the reactive state are masked.
|
|
49
|
+
|
|
50
|
+
- b995afb: Make `incident` a plugin-backed reactive entity via the Model-B entity state machine.
|
|
51
|
+
|
|
52
|
+
The `incidents` + `incident_systems` tables are BOTH authoritative AND the `incident` entity's current-state storage - there is no framework `entity_state` row for an incident. `defineEntity` is given a plugin `read` accessor (`IncidentService.getManyEntityStates`) that projects the reactive subset `{ status, severity, systemIds }` straight off those tables, and every reactive-state write goes through `handle.mutate` / `handle.remove`: `apply` performs the REAL `incidents` / junction write (the plugin's own db/tx) and returns the new state; the framework snapshots `prev` via `read` BEFORE the write, appends the transition log (its own db), and emits `ENTITY_CHANGED` AFTER the write commits. Covered sites: create, update, add-update, resolve, auto-create, auto-resolve, and delete (tombstone), plus the `incident.create` / `incident.resolve` automation actions.
|
|
53
|
+
|
|
54
|
+
A change -> trigger-event deriver reproduces the existing qualified events so automations keep firing:
|
|
55
|
+
|
|
56
|
+
- create (`prev === null`) -> `incident.created`
|
|
57
|
+
- transition to `resolved` -> `incident.resolved`
|
|
58
|
+
- any other field change -> `incident.updated`
|
|
59
|
+
- delete (tombstone) -> no event (there is no `incident.deleted` trigger)
|
|
60
|
+
|
|
61
|
+
The old `incident.created` / `incident.updated` / `incident.resolved` change hooks are removed in favor of these reactive change events; the catalog `system.deleted` consumer switched from `onHook(catalogHooks.systemDeleted)` to `onEntityChanged({ kind: "catalog-system" })` filtered to tombstones, keeping `work-queue` delivery (association cleanup must run once per cluster).
|
|
62
|
+
|
|
63
|
+
BREAKING CHANGES:
|
|
64
|
+
|
|
65
|
+
- The `incident.created` / `incident.updated` / `incident.resolved` cross-plugin hooks (the `createHook` descriptors) are removed. Incident lifecycle is now the reactive `incident` entity; the matching trigger events still fire (via the entity change deriver), so existing automations on `incident.created/.updated/.resolved` and external event-routing (e.g. the Jira integration's `incident.created` event type) keep working. No in-repo plugin subscribed to the removed hooks via `onHook`.
|
|
66
|
+
- The `addUpdate`-with-status=resolved path previously emitted BOTH `incident.updated` and `incident.resolved`; it now fires only `incident.resolved` (the deriver classifies a transition-to-resolved as a resolution). Automations meant to react to a resolution should use the `incident.resolved` trigger, not `incident.updated`.
|
|
67
|
+
- NARROWING: `incident.updated` now fires only on a change to the REACTIVE state (`status`, `severity`, or affected `systemIds`). A comment-only `addUpdate` (no status change) no longer fires `incident.updated` (the posted message is not reactive entity state). Re-author any automation that needed to react to a comment-only update against a different signal.
|
|
68
|
+
- The `incident.create` automation ACTION path now drives its write through `handle.mutate`, so an action-created incident is now reactive - it emits `incident.created` and other automations can trigger on it. Previously the action path created incidents silently (no lifecycle event). A dedupe REUSE still emits nothing (the open incident is unchanged).
|
|
69
|
+
|
|
70
|
+
- b995afb: Restore the documented domain payload fields on entity-driven automation triggers.
|
|
71
|
+
|
|
72
|
+
Migrated triggers declare domain-named `payloadSchema`s (incident `incidentId`; health `systemId` / `previousStatus`; catalog `systemId` / `changedFields`; dependency `dependencyId`), but Stage-2 dispatch built `trigger.payload` from the generic entity-change shape (`{ kind, id, prev, next, delta, ...next }`). Operator filters and templates reading `trigger.payload.incidentId` / `.systemId` / `.previousStatus` silently resolved to `undefined` — a regression vs the legacy hook payloads.
|
|
73
|
+
|
|
74
|
+
Changes:
|
|
75
|
+
|
|
76
|
+
- `@checkstack/automation-backend`: `registerChangeDeriver` now accepts an optional per-kind `toPayload(changed) => Record<string, unknown>` mapper (at most one per kind; a second distinct mapper throws). Stage-2's `changedToPayload` uses the registered mapper to build `trigger.payload` so it matches the kind's declared `payloadSchema`, falling back to the generic change shape for kinds without a mapper. New exported type `EntityChangePayloadMapper`.
|
|
77
|
+
- `@checkstack/incident-backend`, `@checkstack/healthcheck-backend`, `@checkstack/catalog-backend`, `@checkstack/dependency-backend`: implement and register a `toPayload` for each entity-driven kind so `trigger.payload` carries the legacy domain keys again.
|
|
78
|
+
|
|
79
|
+
Descriptive incident payload fields not derivable from the reactive entity state (`title`, `description`, `createdAt`, `resolvedAt`) are now OPTIONAL on the incident trigger `payloadSchema`s — they were always absent from an entity-driven payload.
|
|
80
|
+
|
|
81
|
+
### Patch Changes
|
|
82
|
+
|
|
83
|
+
- 270ef29: Fix suspend/resume durability + complete the run-wide secret-masking guarantee.
|
|
84
|
+
|
|
85
|
+
A panel review confirmed several defects in the automation dispatch engine's suspend/resume durability and in the run-wide masking choke point. These survived because the unit suite stubbed the seam under test; the fixes ship with tests that exercise the real suspend / sweep / resume paths.
|
|
86
|
+
|
|
87
|
+
Suspend/resume durability:
|
|
88
|
+
|
|
89
|
+
- **Stalled sweeper no longer re-runs intentional waits.** `findStalledRunIds` now joins `automation_runs` and returns only `status = 'running'` runs, and suspend-finalisation no longer clobbers the run's `lastActionPath` checkpoint to `null`. Previously any wait longer than the stale window (>60s) was re-walked from the top every sweep cycle, re-firing pre-wait side effects and leaking wait locks. The wait-aware sweeps now also run before the stalled-run sweep.
|
|
90
|
+
- **Stalled recovery refuses a run holding a live wait lock.** `recoverStalledRun` now only recovers a genuinely-`running` run with no wait lock; a crash-mid-wait recovery is left to the wait/resume paths instead of re-walking from the top and creating a duplicate lock + duplicate delay job.
|
|
91
|
+
- **Cancelled runs can no longer resurrect.** `resumeRun` guards on `status === 'waiting'` (mirroring `checkWaitUntil`) and drops any stale lock for a non-waiting run, so `wakeWaitingRuns` / delay-expiry / a racing queue job can't wake a cancelled or terminal run. `cancelActiveRuns` (restart mode) now deletes the cancelled runs' wait locks + run-state in the same operation.
|
|
92
|
+
- **Concurrency check-then-create is serialized.** The `mode` check + `createRun` now run under a transaction-scoped advisory lock keyed on `(automationId, scope)`, so two concurrent fires can't both pass a `single`-mode "no active run" check and double-run.
|
|
93
|
+
|
|
94
|
+
Masking guarantee (now genuinely covers scope + artifacts):
|
|
95
|
+
|
|
96
|
+
- **The run-wide masking choke point now also masks the durable scope snapshot and produced artifacts.** The `RunSecretRegistry` is threaded into `RunStateStore.upsert` (masks `scopeSnapshot`) and `ArtifactStore.record` (masks `data`) so a resolved connection credential threaded into `scope.variables` or surfaced into an artifact is redacted before persist - and therefore cannot reach a read-only user via `getRunScopeForReplay`. **GUARANTEE CHANGE**: run-wide masking now covers step output, run error, scope snapshot, and artifact data for every action.
|
|
97
|
+
- **`testConnection` / `testProviderConnection` mask provider errors.** These RPCs run outside a dispatch run, so they build a per-call mask set from the resolved/submitted connection config and run any provider error through it before returning, so a provider error echoing a token can't cross back to the browser.
|
|
98
|
+
- **Short secrets surface a warning.** `setSecret` now warns when a value is shorter than `MIN_MASKABLE_LENGTH` (4) that it cannot be auto-redacted (the threshold is intentionally not lowered).
|
|
99
|
+
|
|
100
|
+
Internal:
|
|
101
|
+
|
|
102
|
+
- `@checkstack/backend-api`: `withXactLock`'s `fn` now receives the transaction handle `tx` so a critical section can run on the locked connection; the doc clarifies why running on the pool inside the lock window is still safe. The incident dedup caller's comment is corrected accordingly. `RunStore` gains `findWaitLocksByRun`.
|
|
103
|
+
|
|
104
|
+
- b995afb: Extract a shared `withEntityWrite` / `withEntityRemove` guard for PLUGIN-BACKED (Model B) reactive entities and refactor the per-domain copies onto it.
|
|
105
|
+
|
|
106
|
+
Every plugin-backed domain (incident, catalog, dependency, maintenance, slo, satellite) reimplemented the same "no handle wired → run the plugin write directly; handle wired → route through `handle.mutate` / `handle.remove`" guard, varying only in the id-key name. `@checkstack/automation-backend` now exports `withEntityWrite` / `withEntityRemove` (from the entity barrel) and each domain's thin, well-named wrappers (`writeIncidentEntity`, `writeMaintenanceEntity`, satellite's `mirror`, …) delegate to it, so the branch lives in exactly one place. Behavior is unchanged.
|
|
107
|
+
|
|
108
|
+
`writeHealthEntity` (healthcheck-backend) is intentionally NOT migrated onto the helper — it is genuinely bespoke (closure-captured durable state, distinct rethrow-vs-fail-soft branches, a per-system serializer, and it returns the computed state). SLO keeps its fail-soft `onError` wrapper around the shared guard.
|
|
109
|
+
|
|
110
|
+
- Updated dependencies [270ef29]
|
|
111
|
+
- Updated dependencies [b995afb]
|
|
112
|
+
- Updated dependencies [b995afb]
|
|
113
|
+
- Updated dependencies [b995afb]
|
|
114
|
+
- Updated dependencies [270ef29]
|
|
115
|
+
- Updated dependencies [270ef29]
|
|
116
|
+
- Updated dependencies [270ef29]
|
|
117
|
+
- Updated dependencies [270ef29]
|
|
118
|
+
- Updated dependencies [270ef29]
|
|
119
|
+
- Updated dependencies [270ef29]
|
|
120
|
+
- Updated dependencies [270ef29]
|
|
121
|
+
- Updated dependencies [270ef29]
|
|
122
|
+
- Updated dependencies [b995afb]
|
|
123
|
+
- Updated dependencies [b995afb]
|
|
124
|
+
- Updated dependencies [b995afb]
|
|
125
|
+
- Updated dependencies [b995afb]
|
|
126
|
+
- Updated dependencies [270ef29]
|
|
127
|
+
- Updated dependencies [b995afb]
|
|
128
|
+
- Updated dependencies [270ef29]
|
|
129
|
+
- Updated dependencies [b995afb]
|
|
130
|
+
- Updated dependencies [b995afb]
|
|
131
|
+
- Updated dependencies [270ef29]
|
|
132
|
+
- Updated dependencies [b995afb]
|
|
133
|
+
- Updated dependencies [b995afb]
|
|
134
|
+
- Updated dependencies [b995afb]
|
|
135
|
+
- Updated dependencies [b995afb]
|
|
136
|
+
- Updated dependencies [b995afb]
|
|
137
|
+
- Updated dependencies [b995afb]
|
|
138
|
+
- Updated dependencies [b995afb]
|
|
139
|
+
- Updated dependencies [270ef29]
|
|
140
|
+
- Updated dependencies [270ef29]
|
|
141
|
+
- Updated dependencies [270ef29]
|
|
142
|
+
- Updated dependencies [270ef29]
|
|
143
|
+
- Updated dependencies [270ef29]
|
|
144
|
+
- Updated dependencies [270ef29]
|
|
145
|
+
- Updated dependencies [270ef29]
|
|
146
|
+
- Updated dependencies [270ef29]
|
|
147
|
+
- Updated dependencies [270ef29]
|
|
148
|
+
- Updated dependencies [270ef29]
|
|
149
|
+
- Updated dependencies [b995afb]
|
|
150
|
+
- Updated dependencies [b995afb]
|
|
151
|
+
- @checkstack/backend-api@0.19.0
|
|
152
|
+
- @checkstack/automation-backend@0.3.0
|
|
153
|
+
- @checkstack/automation-common@0.3.0
|
|
154
|
+
- @checkstack/catalog-backend@1.3.0
|
|
155
|
+
- @checkstack/integration-backend@0.3.0
|
|
156
|
+
- @checkstack/cache-api@0.3.7
|
|
157
|
+
- @checkstack/command-backend@0.1.32
|
|
158
|
+
- @checkstack/cache-utils@0.2.12
|
|
159
|
+
|
|
160
|
+
## 1.3.0
|
|
161
|
+
|
|
162
|
+
### Minor Changes
|
|
163
|
+
|
|
164
|
+
- 41c77f4: feat(automation): type enum-able trigger/artifact fields as enums for editor value autocompletion
|
|
165
|
+
|
|
166
|
+
The automation editor's staged completion offers concrete values after a
|
|
167
|
+
comparator (`{{ trigger.payload.severity == "high" }}`) only when the
|
|
168
|
+
field's JSON Schema carries an `enum`. Several trigger payload + artifact
|
|
169
|
+
schemas declared closed-set fields as loose `z.string()`, so no values
|
|
170
|
+
were suggested. Tightened them to the canonical enums that already
|
|
171
|
+
existed in each plugin's `-common` package (and matched the hook payload
|
|
172
|
+
types in lockstep so the trigger's `payloadSchema` and `hook` keep the
|
|
173
|
+
same `TPayload`):
|
|
174
|
+
|
|
175
|
+
- **incident** — trigger payloads: `severity` → `IncidentSeverityEnum`,
|
|
176
|
+
`status` / `statusChange` → `IncidentStatusEnum`.
|
|
177
|
+
- **healthcheck** — trigger payloads: `previousStatus` / `newStatus` /
|
|
178
|
+
`status` → `HealthCheckStatusSchema` (across systemDegraded,
|
|
179
|
+
systemHealthy, systemHealthChanged, checkFailed; plus checkCompleted's
|
|
180
|
+
hook type).
|
|
181
|
+
- **dependency** — trigger + artifact: `impactType` → `ImpactTypeSchema`;
|
|
182
|
+
impactPropagated `previousState` / `newState` → `DerivedStateSchema`.
|
|
183
|
+
Also deduped the inline `impactTypeSchema` action-config enum to reuse
|
|
184
|
+
the canonical `ImpactTypeSchema`.
|
|
185
|
+
- **maintenance** — trigger + artifact: `status` →
|
|
186
|
+
`MaintenanceStatusEnum`; deduped the inline `maintenanceStatusEnum`
|
|
187
|
+
(used by `add_update.statusChange`) to the canonical one.
|
|
188
|
+
- **slo** — `achievement.unlocked` trigger + hook: `achievement` →
|
|
189
|
+
`AchievementTypeSchema`.
|
|
190
|
+
|
|
191
|
+
Runtime behaviour is unchanged — these fields always carried valid enum
|
|
192
|
+
values (the underlying records are enum-constrained); only the schema
|
|
193
|
+
types were loose. The hook payload generics are now precise too, which
|
|
194
|
+
caught one stale test fixture asserting an invalid `impactType: "soft"`.
|
|
195
|
+
|
|
196
|
+
Fields that look enum-ish but are genuinely free-form were intentionally
|
|
197
|
+
left as `z.string()`: satellite `region` (user-entered), Jira issue
|
|
198
|
+
`status` (per-instance workflow name), notification `strategyQualifiedId`
|
|
199
|
+
/ `errorMessage`, healthcheck collector `result`, and script
|
|
200
|
+
`stdout` / `stderr`.
|
|
201
|
+
|
|
202
|
+
- 41c77f4: feat(incident): register incident lifecycle as automation triggers + actions
|
|
203
|
+
|
|
204
|
+
Adds three triggers (`incident.created`, `incident.updated`,
|
|
205
|
+
`incident.resolved`) backed by the existing hooks, each exposing
|
|
206
|
+
`incidentId` as the context key so `wait_for_trigger` waits match the
|
|
207
|
+
same incident across the run. Adds four actions (`incident.create`,
|
|
208
|
+
`incident.resolve`, `incident.add_update`, `incident.update_status`)
|
|
209
|
+
wrapping the existing `IncidentService` methods so operators can compose
|
|
210
|
+
incident flows in the Automation editor.
|
|
211
|
+
|
|
212
|
+
### Patch Changes
|
|
213
|
+
|
|
214
|
+
- Updated dependencies [e2d6f25]
|
|
215
|
+
- Updated dependencies [41c77f4]
|
|
216
|
+
- Updated dependencies [e1a2077]
|
|
217
|
+
- Updated dependencies [41c77f4]
|
|
218
|
+
- Updated dependencies [41c77f4]
|
|
219
|
+
- Updated dependencies [41c77f4]
|
|
220
|
+
- Updated dependencies [41c77f4]
|
|
221
|
+
- Updated dependencies [41c77f4]
|
|
222
|
+
- Updated dependencies [41c77f4]
|
|
223
|
+
- Updated dependencies [41c77f4]
|
|
224
|
+
- Updated dependencies [41c77f4]
|
|
225
|
+
- Updated dependencies [4832e33]
|
|
226
|
+
- Updated dependencies [6d52276]
|
|
227
|
+
- Updated dependencies [6d52276]
|
|
228
|
+
- Updated dependencies [35bc682]
|
|
229
|
+
- @checkstack/automation-backend@0.2.0
|
|
230
|
+
- @checkstack/automation-common@0.2.0
|
|
231
|
+
- @checkstack/integration-backend@0.2.0
|
|
232
|
+
- @checkstack/integration-common@0.6.0
|
|
233
|
+
- @checkstack/catalog-backend@1.2.0
|
|
234
|
+
- @checkstack/common@0.12.0
|
|
235
|
+
- @checkstack/backend-api@0.18.0
|
|
236
|
+
- @checkstack/catalog-common@2.2.3
|
|
237
|
+
- @checkstack/incident-common@1.3.1
|
|
238
|
+
- @checkstack/auth-common@0.7.2
|
|
239
|
+
- @checkstack/command-backend@0.1.31
|
|
240
|
+
- @checkstack/notification-common@1.2.1
|
|
241
|
+
- @checkstack/signal-common@0.2.5
|
|
242
|
+
- @checkstack/cache-api@0.3.6
|
|
243
|
+
- @checkstack/cache-utils@0.2.11
|
|
244
|
+
|
|
3
245
|
## 1.2.0
|
|
4
246
|
|
|
5
247
|
### Minor Changes
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@checkstack/incident-backend",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.4.0",
|
|
4
4
|
"license": "Elastic-2.0",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "src/index.ts",
|
|
@@ -14,27 +14,29 @@
|
|
|
14
14
|
"lint:code": "eslint . --max-warnings 0"
|
|
15
15
|
},
|
|
16
16
|
"dependencies": {
|
|
17
|
-
"@checkstack/backend-api": "0.
|
|
18
|
-
"@checkstack/cache-api": "0.3.
|
|
19
|
-
"@checkstack/cache-utils": "0.2.
|
|
20
|
-
"@checkstack/incident-common": "1.
|
|
21
|
-
"@checkstack/catalog-common": "2.2.
|
|
22
|
-
"@checkstack/catalog-backend": "1.
|
|
23
|
-
"@checkstack/notification-common": "1.2.
|
|
24
|
-
"@checkstack/auth-common": "0.7.
|
|
25
|
-
"@checkstack/command-backend": "0.1.
|
|
26
|
-
"@checkstack/signal-common": "0.2.
|
|
27
|
-
"@checkstack/integration-backend": "0.
|
|
28
|
-
"@checkstack/integration-common": "0.
|
|
29
|
-
"@checkstack/
|
|
17
|
+
"@checkstack/backend-api": "0.18.0",
|
|
18
|
+
"@checkstack/cache-api": "0.3.6",
|
|
19
|
+
"@checkstack/cache-utils": "0.2.11",
|
|
20
|
+
"@checkstack/incident-common": "1.3.1",
|
|
21
|
+
"@checkstack/catalog-common": "2.2.3",
|
|
22
|
+
"@checkstack/catalog-backend": "1.2.0",
|
|
23
|
+
"@checkstack/notification-common": "1.2.1",
|
|
24
|
+
"@checkstack/auth-common": "0.7.2",
|
|
25
|
+
"@checkstack/command-backend": "0.1.31",
|
|
26
|
+
"@checkstack/signal-common": "0.2.5",
|
|
27
|
+
"@checkstack/integration-backend": "0.2.0",
|
|
28
|
+
"@checkstack/integration-common": "0.6.0",
|
|
29
|
+
"@checkstack/automation-backend": "0.2.0",
|
|
30
|
+
"@checkstack/automation-common": "0.2.0",
|
|
31
|
+
"@checkstack/common": "0.12.0",
|
|
30
32
|
"drizzle-orm": "^0.45.0",
|
|
31
33
|
"zod": "^4.2.1",
|
|
32
34
|
"@orpc/server": "^1.13.2"
|
|
33
35
|
},
|
|
34
36
|
"devDependencies": {
|
|
35
37
|
"@checkstack/drizzle-helper": "0.0.5",
|
|
36
|
-
"@checkstack/scripts": "0.3.
|
|
37
|
-
"@checkstack/test-utils-backend": "0.1.
|
|
38
|
+
"@checkstack/scripts": "0.3.4",
|
|
39
|
+
"@checkstack/test-utils-backend": "0.1.31",
|
|
38
40
|
"@checkstack/tsconfig": "0.0.7",
|
|
39
41
|
"@types/bun": "^1.0.0",
|
|
40
42
|
"drizzle-kit": "^0.31.10",
|