@checkstack/slo-common 0.4.2 → 0.5.0

package/CHANGELOG.md

@@ -1,5 +1,43 @@
 # @checkstack/slo-common
 
+## 0.5.0
+
+### Minor Changes
+
+- 9dcc848: Align workspace dependency versions and migrate React Router to v7.
+
+  BREAKING CHANGES (React Router v7): All frontend packages now depend on `react-router-dom@^7.16.0`. Previously the workspace declared four divergent ranges (`^6.20.0`, `^6.22.0`, `^7.1.1`, `^7.14.2`), which resolved both `react-router@6` and `react-router@7` into a single bundle. Everything is now unified on v7. The public imports the app uses (`BrowserRouter`, `Routes`, `Route`, `Link`, `NavLink`, `MemoryRouter`, `useNavigate`, `useParams`, `useSearchParams`, `useLocation`) are unchanged between v6 and v7, so no source rewrites were required - but any out-of-tree plugin still on react-router v6 should upgrade to v7 (see the React Router v6 -> v7 upgrade guide) to share the host's single router instance via the import map.
+
+  Other unified ranges (no API change): `react` -> `^18.3.1`, the `@orpc/*` family (`contract`, `server`, `client`, `tanstack-query`, `openapi`, `zod`) -> `^1.14.4`, and `better-auth` -> `^1.6.13`.
+
+  Removed the pre-rename `@orpc/react-query` leftover from `@checkstack/frontend-api`; its `createRouterUtils` / `RouterUtils` / `ProcedureUtils` now come from `@orpc/tanstack-query` (the package already in use).
+
+  Stale in-range runtime deps pulled up to current published versions: `hono` `^4.12.23`, `@tanstack/react-query` (+devtools) `^5.100.14`, `date-fns` `^4.4.0`, `jose` `^6.2.3`, `tar` `^7.5.16`, `semver` `^7.8.1`, `@xyflow/react` `^12.11.0`.
+
+### Patch Changes
+
+- 9dcc848: Input-validation and error-mapping hardening found by a fuzzing pass against the built container.
+
+  - backend: a Postgres driver error caused by bad client input no longer surfaces as a `500`. The `/api` and `/rest` dispatchers now map the relevant SQLSTATE classes to the correct status - `22P02`/`22003`/`22001`/`22007` (malformed/out-of-range/over-long/bad-date value), `23502`/`23503`/`23514` (missing/dangling/check-failed) to `400`, and `23505` (unique violation) to `409` - and log them at `warn` (client mistake), not `error`. The client-facing message is generic so column/constraint names are never leaked; genuine unknown faults still log at `error` and 500. Previously a `where id = $1` with a non-uuid `$1` (or an over-long string, or a foreign-key miss in `addSystemToGroup`) reached the driver and 500'd, making routine probing look like a server outage and burying real 500s.
+  - slo-common: **fixes a stored cluster-wide DoS.** `windowDays` was accepted up to `2^53`, but the SLO engine derives window boundaries with `Date(now - windowDays * 86_400_000)` - a large value overflows past the max representable `Date` and yields `Invalid Date`. That objective committed fine, then every subsequent read of the system's objectives threw `RangeError: Invalid time value` during serialization (a 500 readable by anyone with SLO read access, on any pod). `windowDays` is now bounded to 1..3650 days at the contract, the GitOps `kind: SLO` spec, and the update path via a single shared `SloWindowDaysSchema`, so the poison row can never be created.
+  - slo-common + healthcheck-common: SLO `getDailySnapshots` and the healthcheck history endpoints (`getHistory`, `getDetailedHistory`, `getAggregatedHistory`, `getDetailedAggregatedHistory`, `getRunsForAnalysis`) declared their `startDate`/`endDate` params as `z.date()`, which a `/rest/...` string param can never satisfy - so those endpoints 400'd on the entire REST surface. They now use `z.coerce.date()`, accepting both the REST string shape and the native RPC `Date`.
+  - healthcheck-common: `intervalSeconds` was `z.number().min(1)` with no `.int()` and no upper bound, so a fractional or out-of-range value reached the DB and failed at insert (the column is a 32-bit int). It is now `.int().min(1).max(2_592_000)` (1 second .. 30 days), applied to both create and update (the update schema is the create partial).
+  - catalog-common: system/group/environment names were bare `z.string()` (environment was `.min(1)` only), so empty, whitespace-only, and 100KB+ names reached the DB - the huge ones surfaced as 500s when parameter binding blew up. Names are now `trim().min(1).max(200)` via a shared schema.
+
+    **BREAKING:** `getSystemContacts` is now `userType: "authenticated"` (was `"public"`). System contacts carry PII (user id, name, email); the public read leaked them to anonymous status-page visitors. Anonymous callers now receive `401` for this one endpoint; the system detail page already renders "No contacts assigned" for anonymous viewers, so the UI degrades gracefully. All other catalog reads remain public.
+
+  - catalog-frontend: the system detail page skips the `getSystemContacts` request entirely for anonymous viewers (it would now `401`) and falls back to the empty state.
+
+  This is a beta release: the breaking contact-visibility change ships as a minor bump per the beta versioning policy, not a major.
+
+- Updated dependencies [9dcc848]
+- Updated dependencies [9dcc848]
+- Updated dependencies [9dcc848]
+- Updated dependencies [9dcc848]
+  - @checkstack/common@0.13.0
+  - @checkstack/frontend-api@0.7.0
+  - @checkstack/signal-common@0.2.6
+
 ## 0.4.2
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/slo-common",
-  "version": "0.4.2",
+  "version": "0.5.0",
   "license": "Elastic-2.0",
   "type": "module",
   "exports": {
@@ -9,16 +9,16 @@
     }
   },
   "dependencies": {
-    "@checkstack/common": "0.11.0",
-    "@checkstack/frontend-api": "0.5.2",
-    "@checkstack/signal-common": "0.2.4",
-    "@orpc/contract": "^1.13.14",
+    "@checkstack/common": "0.12.0",
+    "@checkstack/frontend-api": "0.6.0",
+    "@checkstack/signal-common": "0.2.5",
+    "@orpc/contract": "^1.14.4",
     "zod": "^4.2.1"
   },
   "devDependencies": {
     "typescript": "^5.7.2",
     "@checkstack/tsconfig": "0.0.7",
-    "@checkstack/scripts": "0.3.3"
+    "@checkstack/scripts": "0.3.4"
   },
   "scripts": {
     "typecheck": "tsgo -b",

package/src/index.ts

@@ -14,6 +14,8 @@ export {
   SloStatusSchema,
   CreateSloObjectiveInputSchema,
   UpdateSloObjectiveInputSchema,
+  SloWindowDaysSchema,
+  SLO_MAX_WINDOW_DAYS,
   type DependencyExclusionMode,
   type AttributionType,
   type AchievementType,

package/src/rpc-contract.test.ts

@@ -0,0 +1,44 @@
+import { describe, expect, test } from "bun:test";
+import type { ZodType } from "zod";
+import { sloContract } from "./rpc-contract";
+
+/**
+ * The REST/OpenAPI surface (`/rest/...`) sends query params as strings. With the
+ * date params declared as `z.date()` they were unsatisfiable over REST (a string
+ * never validates as a native Date), so `getDailySnapshots` 400'd on every REST
+ * call. `z.coerce.date()` accepts both an ISO string (REST) and a Date (native
+ * RPC), which is what this guards.
+ */
+function inputSchemaFor(procName: keyof typeof sloContract): ZodType {
+  const proc = sloContract[procName] as unknown as Record<string, unknown>;
+  const orpc = proc["~orpc"] as { inputSchema?: ZodType };
+  if (!orpc.inputSchema) throw new Error(`${String(procName)} has no input`);
+  return orpc.inputSchema;
+}
+
+describe("getDailySnapshots coerces string date params (REST compatibility)", () => {
+  const schema = inputSchemaFor("getDailySnapshots");
+
+  test("accepts ISO date strings (the REST shape)", () => {
+    const parsed = schema.safeParse({
+      objectiveId: "obj-1",
+      startDate: "2026-01-01T00:00:00.000Z",
+      endDate: "2026-02-01T00:00:00.000Z",
+    });
+    expect(parsed.success).toBe(true);
+    if (parsed.success) {
+      const data = parsed.data as { startDate: Date; endDate: Date };
+      expect(data.startDate).toBeInstanceOf(Date);
+      expect(data.endDate).toBeInstanceOf(Date);
+    }
+  });
+
+  test("still accepts native Date objects (the RPC shape)", () => {
+    const parsed = schema.safeParse({
+      objectiveId: "obj-1",
+      startDate: new Date("2026-01-01"),
+      endDate: new Date("2026-02-01"),
+    });
+    expect(parsed.success).toBe(true);
+  });
+});

package/src/rpc-contract.ts

@@ -145,8 +145,8 @@ export const sloContract = {
     .input(
       z.object({
         objectiveId: z.string(),
-        startDate: z.date(),
-        endDate: z.date(),
+        startDate: z.coerce.date(),
+        endDate: z.coerce.date(),
       }),
     )
     .output(z.object({ snapshots: z.array(SloDailySnapshotSchema) })),

package/src/schemas.test.ts

@@ -0,0 +1,56 @@
+import { describe, expect, test } from "bun:test";
+import {
+  CreateSloObjectiveInputSchema,
+  SLO_MAX_WINDOW_DAYS,
+  SloWindowDaysSchema,
+} from "./schemas";
+
+/**
+ * `windowDays` is the load-bearing bound: the engine derives window boundaries
+ * with `Date(now - windowDays * 86_400_000)`, so an unbounded value overflows
+ * past the max representable Date and produces `Invalid Date`. That row commits
+ * but then poisons EVERY read of the system's objectives (the serializer throws
+ * `RangeError: Invalid time value`) - a stored cluster-wide DoS the fuzzing pass
+ * found. The schema bound is what prevents the poison row from ever existing.
+ */
+describe("SloWindowDaysSchema", () => {
+  test("accepts a normal window", () => {
+    expect(SloWindowDaysSchema.parse(30)).toBe(30);
+    expect(SloWindowDaysSchema.parse(SLO_MAX_WINDOW_DAYS)).toBe(
+      SLO_MAX_WINDOW_DAYS,
+    );
+  });
+
+  test("rejects zero and negative windows", () => {
+    expect(SloWindowDaysSchema.safeParse(0).success).toBe(false);
+    expect(SloWindowDaysSchema.safeParse(-1).success).toBe(false);
+  });
+
+  test("rejects non-integer windows", () => {
+    expect(SloWindowDaysSchema.safeParse(1.5).success).toBe(false);
+  });
+
+  test("rejects the date-poisoning value above the max", () => {
+    expect(SloWindowDaysSchema.safeParse(SLO_MAX_WINDOW_DAYS + 1).success).toBe(
+      false,
+    );
+    // The exact value the fuzzer used to poison the SLO read path.
+    expect(SloWindowDaysSchema.safeParse(100_000_000).success).toBe(false);
+  });
+
+  test("a max-window objective produces a valid Date in the engine arithmetic", () => {
+    const windowStart = new Date(
+      Date.now() - SLO_MAX_WINDOW_DAYS * 24 * 60 * 60 * 1000,
+    );
+    expect(Number.isNaN(windowStart.getTime())).toBe(false);
+  });
+
+  test("CreateSloObjectiveInputSchema rejects an out-of-range window", () => {
+    const result = CreateSloObjectiveInputSchema.safeParse({
+      systemId: "sys-1",
+      target: 99.9,
+      windowDays: 100_000_000,
+    });
+    expect(result.success).toBe(false);
+  });
+});

package/src/schemas.ts

@@ -184,6 +184,23 @@ export type SloStatus = z.infer<typeof SloStatusSchema>;
 // INPUT SCHEMAS
 // =============================================================================
 
+/**
+ * SLO rolling-window length in days. Bounded on BOTH ends: at least 1 day, and
+ * at most 10 years. The upper bound is load-bearing - the engine derives window
+ * boundaries with `Date(now - windowDays * 86_400_000)`, so an unbounded value
+ * (the API previously accepted any positive int up to 2^53) overflows past the
+ * max representable Date and produces `Invalid Date`. That row commits fine but
+ * then poisons EVERY read of the system's objectives (the serializer throws
+ * `RangeError: Invalid time value`), a stored cluster-wide DoS. 3650 days keeps
+ * all arithmetic well inside Date and int32 range.
+ */
+export const SLO_MAX_WINDOW_DAYS = 3650;
+export const SloWindowDaysSchema = z
+  .number()
+  .int()
+  .positive("Window must be at least 1 day")
+  .max(SLO_MAX_WINDOW_DAYS, `Window must be at most ${SLO_MAX_WINDOW_DAYS} days`);
+
 /**
  * Input for creating a new SLO objective.
  */
@@ -194,7 +211,7 @@ export const CreateSloObjectiveInputSchema = z.object({
     .number()
     .min(0, "Target must be >= 0")
     .max(100, "Target must be <= 100"),
-  windowDays: z.number().int().positive("Window must be at least 1 day"),
+  windowDays: SloWindowDaysSchema,
   dependencyExclusion: DependencyExclusionModeSchema.optional().default(
     "strict",
   ),
@@ -215,7 +232,7 @@ export type CreateSloObjectiveInput = z.infer<
 export const UpdateSloObjectiveInputSchema = z.object({
   id: z.string(),
   target: z.number().min(0).max(100).optional(),
-  windowDays: z.number().int().positive().optional(),
+  windowDays: SloWindowDaysSchema.optional(),
   dependencyExclusion: DependencyExclusionModeSchema.optional(),
   excludedDependencyIds: z.array(z.string()).optional(),
   burnRateThresholds: BurnRateThresholdsSchema.optional(),