@bli-cockpit/telemetry-core 0.1.18 → 0.1.20

package/dist/evidence-upload.d.ts

@@ -377,6 +377,78 @@ export declare const RawEvidenceUploadCommitResponseSchema: z.ZodObject<{
     }, z.core.$strict>>;
 }, z.core.$strict>;
 export type RawEvidenceUploadCommitResponse = z.infer<typeof RawEvidenceUploadCommitResponseSchema>;
+/**
+ * The collector giving up on an object it already opened (BLI-2539).
+ *
+ * `begin` writes a ledger row for every object in the batch, then chunks go one
+ * object at a time. When one object's chunks fail its siblings still finish, so
+ * the production shape is a single failure among committed rows rather than a
+ * truncated batch. The collector knows exactly why that object died — it
+ * composes labels like `chunk_0_failed_http_500` — and until this route existed
+ * it had nowhere to send them: begin/chunk/commit has no call meaning "I quit".
+ * The row stayed `pending` with a null reason until a drain relabelled it
+ * `staging_incomplete`, which describes the shape and not the cause. 275 rows
+ * reached that state by 2026-08-14.
+ *
+ * The reason is a label, never free text or an error body: it lands in
+ * `status_reason`, which is read by `classifyUploadFailure`, and an unlisted
+ * label classifies as `unknown` rather than being guessed into a bucket. That
+ * is also what keeps these rows recoverable — `unknown` is not permanent, so
+ * the row stays open (still `pending`, staged chunks intact) and the next
+ * `begin` resumes it. Only a reason classified permanent fails the row closed.
+ */
+export declare const RawEvidenceUploadAbortRequestSchema: z.ZodObject<{
+    schema_version: z.ZodLiteral<"ambient-raw-evidence-upload-abort.v1">;
+    generated_at: z.ZodString;
+    provenance: z.ZodObject<{
+        capture_source: z.ZodEnum<{
+            unknown: "unknown";
+            codex_jsonl: "codex_jsonl";
+            codex_otel: "codex_otel";
+            car_state: "car_state";
+            git_state: "git_state";
+            github_state: "github_state";
+            linear_state: "linear_state";
+            mcp_local: "mcp_local";
+            claude_jsonl: "claude_jsonl";
+            claude_hooks: "claude_hooks";
+            manual_event: "manual_event";
+            collector_runtime: "collector_runtime";
+        }>;
+        capture_adapter_version: z.ZodString;
+        collector_version: z.ZodString;
+        repo: z.ZodString;
+        branch: z.ZodString;
+        repo_label: z.ZodOptional<z.ZodString>;
+        repo_fingerprint: z.ZodOptional<z.ZodString>;
+        repo_origin_url: z.ZodOptional<z.ZodString>;
+        worktree_label: z.ZodOptional<z.ZodString>;
+        worktree_fingerprint: z.ZodOptional<z.ZodString>;
+        worktree_is_primary: z.ZodOptional<z.ZodBoolean>;
+        operator_id: z.ZodString;
+        session_id: z.ZodString;
+        work_context_id: z.ZodString;
+    }, z.core.$strict>;
+    upload_id: z.ZodString;
+    object_key: z.ZodString;
+    reason: z.ZodString;
+    uploaded_chunk_count: z.ZodOptional<z.ZodNumber>;
+}, z.core.$strict>;
+export type RawEvidenceUploadAbortRequest = z.infer<typeof RawEvidenceUploadAbortRequestSchema>;
+export declare const RawEvidenceUploadAbortResponseSchema: z.ZodObject<{
+    ok: z.ZodLiteral<true>;
+    status: z.ZodEnum<{
+        reason_recorded: "reason_recorded";
+        aborted: "aborted";
+        already_terminal: "already_terminal";
+    }>;
+    upload_id: z.ZodString;
+    object_key: z.ZodString;
+    status_reason: z.ZodString;
+    retryable: z.ZodBoolean;
+    will_reopen: z.ZodBoolean;
+}, z.core.$strict>;
+export type RawEvidenceUploadAbortResponse = z.infer<typeof RawEvidenceUploadAbortResponseSchema>;
 /**
  * Codex session attribution report.
  *

package/dist/evidence-upload.js

@@ -19,11 +19,22 @@ export const RAW_EVIDENCE_UPLOAD_DEFAULT_CHUNK_BYTES = RAW_EVIDENCE_UPLOAD_MAX_C
 // by Vercel's ~4.5MB request-body limit (see header comment). 192 chunks
 // * 3 MiB gives a 576 MiB protocol ceiling above the current file cap.
 export const RAW_EVIDENCE_UPLOAD_MAX_CHUNK_COUNT = 192;
-// Final-object cap. The commit route still assembles and redaction-scans text
-// in memory, so keep this below V8's string ceiling with practical headroom for
-// buffers and redaction copies. 256 MiB covers the largest observed fleet
-// session (118 MiB) with >2x headroom. Raising it requires a streaming commit.
-export const RAW_EVIDENCE_UPLOAD_MAX_FILE_BYTES = 256 * 1024 * 1024;
+// Final-object cap. The server's Supabase project-level (global) storage
+// limit was raised from 50 MiB to 512 MiB on 2026-07-04 (BLI-2528; see
+// docs/runbooks/cockpit-stuck-evidence-uploads.md) after that ceiling silently
+// rejected every larger raw-evidence object for 57 days, so this constant must
+// track the server's real ceiling rather than trail it. It cannot simply BE
+// 512 MiB, though: the commit route (apps/dashboard .../evidence/upload/commit)
+// still assembles the object into one Buffer and calls
+// `assembled.toString("utf8")` for the secret-content scan, and 512 MiB
+// (536,870,912 bytes) is 24 bytes PAST V8's `MAX_STRING_LENGTH`
+// (536,870,888 on Node 22 / this repo's pinned runtime) — a file at the literal
+// 512 MiB ceiling would crash the commit route with a RangeError instead of
+// committing, the same silent-loss failure mode BLI-2528 was about. 500 MiB
+// keeps ~12.6 MiB of real headroom under that hard ceiling for the
+// Buffer.concat + string-conversion overhead, while still fitting the chunk
+// protocol's 576 MiB ceiling (192 chunks * 3 MiB).
+export const RAW_EVIDENCE_UPLOAD_MAX_FILE_BYTES = 500 * 1024 * 1024;
 export const RAW_EVIDENCE_UPLOAD_MAX_OBJECTS_PER_BEGIN = 25;
 export const CODEX_SESSION_REPORT_MAX_SESSIONS = 200;
 const SafeLabelSchema = z
@@ -154,6 +165,72 @@ export const RawEvidenceUploadCommitResponseSchema = z
     redaction: RawEvidenceRedactionMetadataSchema.optional(),
 })
     .strict();
+/**
+ * The collector giving up on an object it already opened (BLI-2539).
+ *
+ * `begin` writes a ledger row for every object in the batch, then chunks go one
+ * object at a time. When one object's chunks fail its siblings still finish, so
+ * the production shape is a single failure among committed rows rather than a
+ * truncated batch. The collector knows exactly why that object died — it
+ * composes labels like `chunk_0_failed_http_500` — and until this route existed
+ * it had nowhere to send them: begin/chunk/commit has no call meaning "I quit".
+ * The row stayed `pending` with a null reason until a drain relabelled it
+ * `staging_incomplete`, which describes the shape and not the cause. 275 rows
+ * reached that state by 2026-08-14.
+ *
+ * The reason is a label, never free text or an error body: it lands in
+ * `status_reason`, which is read by `classifyUploadFailure`, and an unlisted
+ * label classifies as `unknown` rather than being guessed into a bucket. That
+ * is also what keeps these rows recoverable — `unknown` is not permanent, so
+ * the row stays open (still `pending`, staged chunks intact) and the next
+ * `begin` resumes it. Only a reason classified permanent fails the row closed.
+ */
+export const RawEvidenceUploadAbortRequestSchema = z
+    .object({
+    schema_version: z.literal("ambient-raw-evidence-upload-abort.v1"),
+    generated_at: IsoDateTimeSchema,
+    provenance: CaptureProvenanceSchema,
+    upload_id: NonEmptyStringSchema,
+    object_key: NonEmptyStringSchema,
+    reason: SafeLabelSchema,
+    // How far the object actually got before the collector gave up. The server
+    // already knows the received chunk count; this is what the CLIENT believed,
+    // and a disagreement between the two is itself worth being able to see.
+    uploaded_chunk_count: z.number().int().nonnegative().optional(),
+})
+    .strict();
+export const RawEvidenceUploadAbortResponseSchema = z
+    .object({
+    ok: z.literal(true),
+    // `reason_recorded` is the ordinary answer: the reason landed on the
+    // still-open row, whose staged chunks stay resumable by the next `begin`.
+    // `aborted` means the reason was classified permanent and the row failed
+    // closed. `already_terminal` covers a row the server had already settled —
+    // a drain that ran first, or a duplicate abort after a retry. Reporting
+    // these back distinguishes "we recorded your reason" from "someone beat
+    // you to it", which a bare 200 would hide.
+    status: z.enum(["reason_recorded", "aborted", "already_terminal"]),
+    upload_id: NonEmptyStringSchema,
+    object_key: NonEmptyStringSchema,
+    status_reason: SafeLabelSchema,
+    // Two booleans because the underlying questions are not each other's
+    // negation, and one field would have to lie about half of them.
+    //
+    // `retryable` is `isRetryableUploadFailure`: is repeating this KNOWN to
+    // help? An unclassified reason answers no — refusing to promise something
+    // nobody has reasoned about.
+    //
+    // `will_reopen` is `!isPermanentUploadFailure`: is this row still open (or
+    // re-openable) for the next `begin`? An unclassified reason answers yes —
+    // refusing to abandon an object over a word it cannot read.
+    //
+    // So a composed transport label like `chunk_0_failed_http_500` comes back
+    // `retryable: false, will_reopen: true`, which is the honest pair: we are
+    // not claiming a retry succeeds, and we are not writing the row off.
+    retryable: z.boolean(),
+    will_reopen: z.boolean(),
+})
+    .strict();
 /**
  * Codex session attribution report.
  *

package/dist/upload-failure-class.js

@@ -45,6 +45,12 @@ const UPLOAD_FAILURE_CLASSES = {
     collection_failed: "transient",
     file_read_failed: "transient",
     git_diff_failed: "transient",
+    // `begin` opens a ledger row per object in a loop with no transaction, so a
+    // throw partway through leaves the earlier rows written while the client sees
+    // one 500 for the batch (BLI-2539: 12 such batches in production). Those rows
+    // now name themselves instead of going silent. Transient because the object
+    // was never offered a chance to upload — nothing about it was refused.
+    begin_batch_server_error: "transient",
     // The file itself is the problem, and it will be the same size and the same
     // shape on the next pass. Retrying is a promise nobody can keep.
     file_too_large: "deterministic",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bli-cockpit/telemetry-core",
-  "version": "0.1.18",
+  "version": "0.1.20",
   "private": false,
   "type": "module",
   "main": "./dist/index.js",