Files
hq/04-ISSUES/328-jetstream-api-errors-are-counted-and-attributed-to-nothing/01-diagnosis.md
T

1.6 KiB

328 — Diagnosis

2026-10-08

What was read. The server's totals, before and after a set of known calls: three mesh-controller.conditions, three mesh-controller.delivery-walks and a dozen nats tool reads added calls and no error. The server's log since it started (2026-10-06 22:24 UTC) holds permission violations, two slow consumers and configuration reloads, and no JetStream API error. The advisory subscriptions on the server are the controller's two (CONSUMER.DELETED, CONSUMER.MAX_DELIVERIES); nothing subscribes to $JS.EVENT.ADVISORY.API, the per-call audit.

Status open. No tool answers which call failed, so the owner cannot be named yet. The first step of the fix is the attribution tool; with it, this diagnosis continues.

Leads, not confirmed.

  • A holder that never said it paused. PausedSaid (controller, internal/link/queue.go) asks for the last message on each build holder's pause subject. A holder that never said one gets a not-found answer, which the server counts as an API error. The serving controller's watchdog reads it every 30 seconds while a rollout waits for a build (issue 327).
  • Short-lived consumers. The controller heard 495 "consumer deleted" advisories in the first 8 minutes of its current connection, about one a second. They are short-lived consumers: the controller's advisory reader (internal/link/advisories.go) ignores them and says why, "every watch of a bucket and every read-back of a stream makes one, many a minute". A request to delete one that the server already removed would be an API error.