@checkstack/backend 0.9.0 → 0.10.0

package/CHANGELOG.md

@@ -1,5 +1,200 @@
 # @checkstack/backend
 
+## 0.10.0
+
+### Minor Changes
+
+- 9016526: Add a `/rest/:pluginId/*` HTTP mount that serves every plugin's oRPC contract
+  through the REST/OpenAPI shape described by `/api/openapi.json`. Queries are
+  `GET` with query parameters, mutations are `POST` with the input as the raw
+  JSON body. The existing `/api/:pluginId/*` mount continues to serve oRPC's
+  native wire protocol unchanged, so existing clients are not affected.
+
+  The OpenAPI spec at `/api/openapi.json` now reflects the real mount: every
+  `paths` entry is prefixed with `/rest` instead of `/api`.
+
+  Also fixes a SPA-fallback bug: the backend's `/api-docs` route previously
+  returned 404 on production deployments because the static-file middleware
+  skipped any path starting with `/api`, capturing `/api-docs` along with real
+  API routes. The skip now requires a trailing slash (`/api/`, `/rest/`).
+
+  Required access rules are now visible in the API Docs UI. The OpenAPI spec
+  generator was reading a non-existent `accessRules` field on procedure
+  metadata; the real field is `access: AccessRule[]`. Each procedure's access
+  rules are now flattened to fully-qualified IDs (e.g. `catalog.system.read`)
+  and emitted under `x-orpc-meta.accessRules`, which the existing
+  `Required Access Rules` section in the docs UI already knew how to render.
+
+  The API Docs schema renderer now handles record types (zod `z.record`),
+  `$ref`s into `components.schemas`, `oneOf`/`anyOf`/`allOf`, nullable union
+  types (`type: ["string", "null"]`), and `format` qualifiers. Previously
+  record outputs like `{ statuses: object }` masked the actual value type;
+  they now render as `{ [key]: <ResolvedType> { ... } }` with the inner
+  schema expanded, capped at 12 levels with cycle detection.
+
+  **REST method conventions.** `proc()` now defaults to `GET` for queries and
+  `POST` for mutations on the `/rest` mount, using bracket-notation query
+  params (`?filter[status]=active&ids[0]=a`) for GET inputs. Existing
+  procedures were updated to follow REST semantics:
+
+  - `update*` mutations → `PATCH`
+  - `delete*` / `remove*` mutations → `DELETE`
+  - `getBulk*` queries and any query taking a large array input → `POST`
+    (because `@orpc/openapi@1.13.x` has no GET→POST URL-length fallback)
+
+  GET endpoints require an `object` input — bare scalars like
+  `.input(z.string())` are not valid on GET. `getSystemConfigurations` was
+  refactored from `.input(z.string())` to `.input(z.object({ systemId: ... }))`
+  to fit the GET shape; the only call-site update was the in-process router
+  unpacking `input.systemId` instead of passing `input` directly.
+
+  The API Docs UI now renders query parameters (path/query/header/cookie) in a
+  dedicated table for GET endpoints, and the fetch example shows them in the
+  URL with `<required>` / `<optional>` placeholders.
+
+### Patch Changes
+
+- Updated dependencies [9016526]
+  - @checkstack/common@0.10.0
+  - @checkstack/auth-common@0.7.0
+  - @checkstack/api-docs-common@0.1.13
+  - @checkstack/backend-api@0.15.2
+  - @checkstack/pluginmanager-common@0.2.2
+  - @checkstack/signal-backend@0.2.5
+  - @checkstack/signal-common@0.2.3
+  - @checkstack/cache-api@0.3.1
+  - @checkstack/queue-api@0.3.1
+
+## 0.9.1
+
+### Patch Changes
+
+- aa89bc5: Replace the bespoke `registerInfrastructureTab()` registry with a standard
+  slot-extension contract (`InfrastructureTabsSlot` from
+  `@checkstack/infrastructure-common`). Plugins now contribute infrastructure
+  tabs via `createSlotExtension`, depending only on the slot owner.
+
+  The slot system in `@checkstack/frontend-api` gains a second type parameter
+  on `createSlot<TContext, TMetadata>` so extensions can declare typed static
+  metadata at registration time (label, icon, access rules, ordering for the
+  infrastructure tab bar). A new `useSlotExtensions(slot)` hook returns typed
+  extensions and subscribes to plugin lifecycle changes.
+
+  Each tab body now stacks a **Runtime** sub-section (live state, read-only)
+  on top of a **Configuration** sub-section (settings, gated by `canUpdate`).
+
+  **Queue runtime panel.** Surfaces aggregated counts (pending / processing /
+  completed / failed) plus three sub-tabs of recent jobs: **Active**, **Recent
+  failed** (with the failure message), and **Recent completed** (with
+  duration). Job payloads are deliberately not surfaced — they may carry
+  secrets and need a separate manage-access gate to be shown.
+
+  To support this, `Queue<T>` gains a required `listJobs(opts)` method
+  returning `JobSummary[]` (no payloads), and `QueueStats` gains a
+  `scope: "instance" | "cluster"` field. The in-memory queue keeps rolling
+  ring buffers (200 entries) for completed/failed history and tracks active
+  jobs by id; BullMQ uses native `getJobs`. `QueueManager.listJobs` aggregates
+  across queues and sorts (most-recent-first for terminal states, FIFO for
+  active/waiting/delayed).
+
+  **Cache runtime panel.** Lists the top N entries by size (or by recency) so
+  operators can debug a cache filling up. Values are deliberately omitted —
+  PII / secret risk. Backends opt in via an optional `listEntries?` method on
+  `CacheProvider`; non-supporting backends return `{ supported: false }` and
+  the UI renders a "not supported by this backend" hint. The in-memory cache
+  implements it using its existing per-entry byte tracking.
+
+  `CacheStats` also gains `scope: "instance" | "cluster"`.
+
+  **Multi-instance scope warning.** A new `<InstanceScopeBanner>` component in
+  `@checkstack/ui` renders a yellow banner above any runtime panel whose
+  backend reports `scope: "instance"` — i.e. in-memory queue or cache running
+  in a horizontally scaled deployment. The banner explains the metrics are
+  local to the responding replica and recommends switching to a clustered
+  backend (Redis-backed queue / cache) for cluster-wide visibility.
+
+  **Bug fix — stable cache provider proxy.** `CacheManagerImpl.getProvider()`
+  now returns a single stable proxy that delegates to whatever provider is
+  currently active. Previously, consumers of `createCachedScope` (and any
+  direct `cacheManager.getProvider()` caller) captured the active provider
+  reference at plugin-init time. After any `setActiveBackend` call — including
+  saving the same memory config in the new Cache tab, which reconstructs the
+  in-memory cache — those scopes wrote to an orphaned old provider while the
+  runtime panel read stats from the new (empty) one, making the runtime panel
+  appear to report 0 keys. With the proxy, all consumers share a single stable
+  identity and writes always land in the active provider.
+
+  **Bytes tracking on the in-memory cache.** `InMemoryCache.getStats().sizeBytes`
+  now returns a running approximation (UTF-8 bytes of the key plus
+  `v8.serialize(value).byteLength`, with a JSON fallback) that's kept in sync
+  across all eviction paths. Treat the number as a sanity gauge; it doesn't
+  include `Map` per-entry overhead.
+
+  **Pagination.** Both `Queue<T>.listJobs` and `CacheProvider.listEntries?`
+  are offset-paginated. Inputs gain an `offset: number`; outputs change to
+  `{ items, total: number | null, hasMore: boolean }`. `total` is nullable
+  so backends that can't compute it cheaply still paginate via `hasMore`.
+  The UI uses the existing `<Pagination>` component with a 25-row default
+  page size. `QueueManager.listJobs` aggregates by over-fetching
+  `[0, offset+limit)` per queue, merge-sorting, then slicing the window —
+  optimal for the single-queue case, acceptable for the multi-queue case
+  within the UI's reasonable page-depth bounds. BullMQ uses native offset
+  ranges via `getJobs(types, start, end)` plus `getJobCounts` for `total`.
+
+  **Pending tab.** The Queue runtime panel exposes a virtual `"pending"`
+  state (waiting ∪ delayed, FIFO). It's now the default sub-tab, since
+  "what's queued up?" is the most common question. Per-row state is shown
+  when viewing the combined list.
+
+  **Recurring schedules visible under Pending.** Cron- and interval-based
+  recurring jobs (e.g. healthchecks) are surfaced under Pending/Delayed
+  between fires, with a `nextRunAt` countdown column and a "(recurring)"
+  label. `JobSummary` gains optional `nextRunAt: Date` and `recurring:
+boolean` fields. The in-memory queue synthesises these rows from its
+  `recurringJobs` registry; BullMQ already materialises the next fire of
+  each scheduler as a delayed job and we now surface its trigger time and
+  the `repeatJobKey`-derived `recurring` flag.
+
+  **Bug fix — drop hook emits with no listeners.** `EventBus.emit` no
+  longer enqueues a job when zero listeners (distributed or instance-local)
+  are registered for the hook. Previously, hooks like
+  `core.plugin.initialized` — emitted on every plugin init but subscribed
+  to by nothing in the core repo — accumulated one waiting job per emit
+  forever. The in-memory queue's `processNext` short-circuits when there
+  are zero consumer groups, so its post-loop cleanup never ran for these
+  orphaned jobs. The fix drops the emit at the source and logs a debug
+  line. Note: in distributed deployments using a Redis-backed queue, this
+  means a subscriber on another replica won't receive an event if no
+  replica that emits it has a local listener. Plugins needing cross-process
+  delivery must register their listener on every replica that should
+  receive the hook.
+
+  **Breaking notes (treated as minor under beta semantics)**:
+
+  - `@checkstack/infrastructure-common` removes `registerInfrastructureTab`
+    and `getInfrastructureTabs`; former callers must register an extension
+    into `InfrastructureTabsSlot`.
+  - `@checkstack/queue-api`'s `Queue<T>` interface requires the new
+    `listJobs(opts)` method returning `ListJobsResult` (paginated). Both
+    bundled queue backends (memory, BullMQ) are updated; out-of-tree
+    implementations will need to add it.
+  - `QueueStats` and `CacheStats` add a required `scope` field.
+  - `CacheProvider.listEntries?` (when implemented) now returns
+    `ListEntriesResult` instead of `CacheEntrySummary[]`.
+  - `JobState` adds a `"pending"` variant.
+
+- Updated dependencies [42abfff]
+- Updated dependencies [aa89bc5]
+  - @checkstack/common@0.9.0
+  - @checkstack/queue-api@0.3.0
+  - @checkstack/cache-api@0.3.0
+  - @checkstack/api-docs-common@0.1.12
+  - @checkstack/auth-common@0.6.6
+  - @checkstack/backend-api@0.15.1
+  - @checkstack/pluginmanager-common@0.2.1
+  - @checkstack/signal-backend@0.2.4
+  - @checkstack/signal-common@0.2.2
+
 ## 0.9.0
 
 ### Minor Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/backend",
-  "version": "0.9.0",
+  "version": "0.10.0",
   "license": "Elastic-2.0",
   "checkstack": {
     "type": "backend"
@@ -14,16 +14,16 @@
     "lint:code": "eslint . --max-warnings 0"
   },
   "dependencies": {
-    "@checkstack/api-docs-common": "0.1.10",
-    "@checkstack/auth-common": "0.6.4",
-    "@checkstack/backend-api": "0.14.1",
-    "@checkstack/common": "0.7.0",
-    "@checkstack/drizzle-helper": "0.0.4",
-    "@checkstack/cache-api": "0.2.3",
-    "@checkstack/queue-api": "0.2.17",
-    "@checkstack/signal-backend": "0.2.2",
-    "@checkstack/signal-common": "0.2.0",
-    "@checkstack/pluginmanager-common": "0.1.0",
+    "@checkstack/api-docs-common": "0.1.12",
+    "@checkstack/auth-common": "0.6.6",
+    "@checkstack/backend-api": "0.15.1",
+    "@checkstack/common": "0.9.0",
+    "@checkstack/drizzle-helper": "0.0.5",
+    "@checkstack/cache-api": "0.3.0",
+    "@checkstack/queue-api": "0.3.0",
+    "@checkstack/signal-backend": "0.2.4",
+    "@checkstack/signal-common": "0.2.2",
+    "@checkstack/pluginmanager-common": "0.2.1",
     "@hono/zod-validator": "^0.7.6",
     "@orpc/client": "^1.13.14",
     "@orpc/contract": "^1.13.14",
@@ -44,9 +44,9 @@
     "@types/pg": "^8.11.0",
     "@types/bun": "latest",
     "@types/semver": "^7.5.0",
-    "@checkstack/tsconfig": "0.0.6",
-    "@checkstack/scripts": "0.1.2",
-    "@checkstack/test-utils-backend": "0.1.23",
+    "@checkstack/tsconfig": "0.0.7",
+    "@checkstack/scripts": "0.3.1",
+    "@checkstack/test-utils-backend": "0.1.25",
     "drizzle-kit": "^0.31.10"
   }
 }

package/src/index.ts

@@ -335,8 +335,13 @@ if (frontendDistPath && fs.existsSync(frontendDistPath)) {
   // Serve root-level static files (e.g., /favicon.svg) from the dist directory
   // before the SPA fallback, so they don't get caught by the index.html handler
   app.get("*", async (c, next) => {
-    // Skip API and WebSocket routes - let them pass through to actual handlers
-    if (c.req.path.startsWith("/api")) {
+    // Skip API and WebSocket routes - let them pass through to actual handlers.
+    // The trailing slash matters: `/api-docs` is a frontend route and must hit
+    // the SPA fallback below, while `/api/...` and `/rest/...` go to backend
+    // handlers (oRPC RPC + OpenAPI REST mounts).
+    const apiPath =
+      c.req.path.startsWith("/api/") || c.req.path.startsWith("/rest/");
+    if (apiPath) {
       return next();
     }
 

package/src/openapi-router.ts

@@ -10,6 +10,7 @@ import { ZodToJsonSchemaConverter } from "@orpc/zod/zod4";
 import type { AnyContractRouter } from "@orpc/contract";
 import type { PluginManager } from "./plugin-manager";
 import type { AuthService } from "@checkstack/backend-api";
+import type { AccessRule } from "@checkstack/common";
 
 /**
  * Check if a user has a specific access rule.
@@ -25,40 +26,57 @@ function hasAccess(
   );
 }
 
+/**
+ * Shape of the metadata we surface in the OpenAPI spec as `x-orpc-meta`.
+ * `accessRules` are the fully-qualified access rule IDs (e.g.
+ * `"catalog.system.read"`), flattened from each procedure's `access`
+ * AccessRule[] so doc consumers don't need to know the AccessRule shape.
+ */
+interface ExposedProcedureMeta {
+  userType?: string;
+  accessRules?: string[];
+}
+
 /**
  * Extract procedure metadata from a contract using oRPC internal structure.
+ * Returns the raw `meta` block stored on the contract procedure builder.
  */
-function extractProcedureMetadata(
+function extractRawProcedureMeta(
   contract: unknown
-): { userType?: string; accessRules?: string[] } | undefined {
+): { userType?: string; access?: AccessRule[] } | undefined {
   const orpcData = (contract as Record<string, unknown>)?.["~orpc"] as
-    | { meta?: { userType?: string; accessRules?: string[] } }
+    | { meta?: { userType?: string; access?: AccessRule[] } }
     | undefined;
   return orpcData?.meta;
 }
 
 /**
- * Build a lookup map of operationId -> metadata from all contracts.
- * operationId format: "pluginId.procedureName"
+ * Build a lookup map of operationId -> exposed metadata from all contracts.
+ * operationId format: "pluginId.procedureName".
+ *
+ * The procedure metadata stores `access` as AccessRule[]; we flatten it to
+ * `accessRules: string[]` of qualified IDs (`{pluginId}.{ruleId}`) so the
+ * OpenAPI consumer (API docs UI, third-party clients) gets a plain list.
  */
 function buildMetadataLookup(
   contracts: Map<string, AnyContractRouter>
-): Map<string, { userType?: string; accessRules?: string[] }> {
-  const lookup = new Map<
-    string,
-    { userType?: string; accessRules?: string[] }
-  >();
+): Map<string, ExposedProcedureMeta> {
+  const lookup = new Map<string, ExposedProcedureMeta>();
 
   for (const [pluginId, contract] of contracts) {
-    // Contract is an object with procedure names as keys
     for (const [procedureName, procedure] of Object.entries(
       contract as Record<string, unknown>
     )) {
-      const meta = extractProcedureMetadata(procedure);
-      if (meta) {
-        const operationId = `${pluginId}.${procedureName}`;
-        lookup.set(operationId, meta);
-      }
+      const raw = extractRawProcedureMeta(procedure);
+      if (!raw) continue;
+
+      const accessRules = raw.access?.map((rule) => `${pluginId}.${rule.id}`);
+
+      const operationId = `${pluginId}.${procedureName}`;
+      lookup.set(operationId, {
+        userType: raw.userType,
+        ...(accessRules && accessRules.length > 0 ? { accessRules } : {}),
+      });
     }
   }
 
@@ -107,13 +125,14 @@ export async function generateOpenApiSpec({
     >;
   };
 
-  // Post-process: Add x-orpc-meta to each operation and prefix paths with /api
+  // Post-process: Add x-orpc-meta to each operation and prefix paths with /rest.
+  // The REST handler is mounted at /rest/:pluginId/* (see api-router.ts);
+  // /api/:pluginId/* serves oRPC's native wire protocol, not REST.
   if (spec.paths) {
     const prefixedPaths: typeof spec.paths = {};
 
     for (const [path, methods] of Object.entries(spec.paths)) {
-      // Prefix path with /api
-      const prefixedPath = `/api${path.startsWith("/") ? path : `/${path}`}`;
+      const prefixedPath = `/rest${path.startsWith("/") ? path : `/${path}`}`;
       prefixedPaths[prefixedPath] = methods;
 
       // Add metadata to each operation