@bli-cockpit/telemetry-core 0.1.18 → 0.1.19

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.
@@ -377,6 +377,78 @@ export declare const RawEvidenceUploadCommitResponseSchema: z.ZodObject<{
377
377
  }, z.core.$strict>>;
378
378
  }, z.core.$strict>;
379
379
  export type RawEvidenceUploadCommitResponse = z.infer<typeof RawEvidenceUploadCommitResponseSchema>;
380
+ /**
381
+ * The collector giving up on an object it already opened (BLI-2539).
382
+ *
383
+ * `begin` writes a ledger row for every object in the batch, then chunks go one
384
+ * object at a time. When one object's chunks fail its siblings still finish, so
385
+ * the production shape is a single failure among committed rows rather than a
386
+ * truncated batch. The collector knows exactly why that object died — it
387
+ * composes labels like `chunk_0_failed_http_500` — and until this route existed
388
+ * it had nowhere to send them: begin/chunk/commit has no call meaning "I quit".
389
+ * The row stayed `pending` with a null reason until a drain relabelled it
390
+ * `staging_incomplete`, which describes the shape and not the cause. 275 rows
391
+ * reached that state by 2026-08-14.
392
+ *
393
+ * The reason is a label, never free text or an error body: it lands in
394
+ * `status_reason`, which is read by `classifyUploadFailure`, and an unlisted
395
+ * label classifies as `unknown` rather than being guessed into a bucket. That
396
+ * is also what keeps these rows recoverable — `unknown` is not permanent, so
397
+ * the row stays open (still `pending`, staged chunks intact) and the next
398
+ * `begin` resumes it. Only a reason classified permanent fails the row closed.
399
+ */
400
+ export declare const RawEvidenceUploadAbortRequestSchema: z.ZodObject<{
401
+ schema_version: z.ZodLiteral<"ambient-raw-evidence-upload-abort.v1">;
402
+ generated_at: z.ZodString;
403
+ provenance: z.ZodObject<{
404
+ capture_source: z.ZodEnum<{
405
+ unknown: "unknown";
406
+ codex_jsonl: "codex_jsonl";
407
+ codex_otel: "codex_otel";
408
+ car_state: "car_state";
409
+ git_state: "git_state";
410
+ github_state: "github_state";
411
+ linear_state: "linear_state";
412
+ mcp_local: "mcp_local";
413
+ claude_jsonl: "claude_jsonl";
414
+ claude_hooks: "claude_hooks";
415
+ manual_event: "manual_event";
416
+ collector_runtime: "collector_runtime";
417
+ }>;
418
+ capture_adapter_version: z.ZodString;
419
+ collector_version: z.ZodString;
420
+ repo: z.ZodString;
421
+ branch: z.ZodString;
422
+ repo_label: z.ZodOptional<z.ZodString>;
423
+ repo_fingerprint: z.ZodOptional<z.ZodString>;
424
+ repo_origin_url: z.ZodOptional<z.ZodString>;
425
+ worktree_label: z.ZodOptional<z.ZodString>;
426
+ worktree_fingerprint: z.ZodOptional<z.ZodString>;
427
+ worktree_is_primary: z.ZodOptional<z.ZodBoolean>;
428
+ operator_id: z.ZodString;
429
+ session_id: z.ZodString;
430
+ work_context_id: z.ZodString;
431
+ }, z.core.$strict>;
432
+ upload_id: z.ZodString;
433
+ object_key: z.ZodString;
434
+ reason: z.ZodString;
435
+ uploaded_chunk_count: z.ZodOptional<z.ZodNumber>;
436
+ }, z.core.$strict>;
437
+ export type RawEvidenceUploadAbortRequest = z.infer<typeof RawEvidenceUploadAbortRequestSchema>;
438
+ export declare const RawEvidenceUploadAbortResponseSchema: z.ZodObject<{
439
+ ok: z.ZodLiteral<true>;
440
+ status: z.ZodEnum<{
441
+ reason_recorded: "reason_recorded";
442
+ aborted: "aborted";
443
+ already_terminal: "already_terminal";
444
+ }>;
445
+ upload_id: z.ZodString;
446
+ object_key: z.ZodString;
447
+ status_reason: z.ZodString;
448
+ retryable: z.ZodBoolean;
449
+ will_reopen: z.ZodBoolean;
450
+ }, z.core.$strict>;
451
+ export type RawEvidenceUploadAbortResponse = z.infer<typeof RawEvidenceUploadAbortResponseSchema>;
380
452
  /**
381
453
  * Codex session attribution report.
382
454
  *
@@ -154,6 +154,72 @@ export const RawEvidenceUploadCommitResponseSchema = z
154
154
  redaction: RawEvidenceRedactionMetadataSchema.optional(),
155
155
  })
156
156
  .strict();
157
+ /**
158
+ * The collector giving up on an object it already opened (BLI-2539).
159
+ *
160
+ * `begin` writes a ledger row for every object in the batch, then chunks go one
161
+ * object at a time. When one object's chunks fail its siblings still finish, so
162
+ * the production shape is a single failure among committed rows rather than a
163
+ * truncated batch. The collector knows exactly why that object died — it
164
+ * composes labels like `chunk_0_failed_http_500` — and until this route existed
165
+ * it had nowhere to send them: begin/chunk/commit has no call meaning "I quit".
166
+ * The row stayed `pending` with a null reason until a drain relabelled it
167
+ * `staging_incomplete`, which describes the shape and not the cause. 275 rows
168
+ * reached that state by 2026-08-14.
169
+ *
170
+ * The reason is a label, never free text or an error body: it lands in
171
+ * `status_reason`, which is read by `classifyUploadFailure`, and an unlisted
172
+ * label classifies as `unknown` rather than being guessed into a bucket. That
173
+ * is also what keeps these rows recoverable — `unknown` is not permanent, so
174
+ * the row stays open (still `pending`, staged chunks intact) and the next
175
+ * `begin` resumes it. Only a reason classified permanent fails the row closed.
176
+ */
177
+ export const RawEvidenceUploadAbortRequestSchema = z
178
+ .object({
179
+ schema_version: z.literal("ambient-raw-evidence-upload-abort.v1"),
180
+ generated_at: IsoDateTimeSchema,
181
+ provenance: CaptureProvenanceSchema,
182
+ upload_id: NonEmptyStringSchema,
183
+ object_key: NonEmptyStringSchema,
184
+ reason: SafeLabelSchema,
185
+ // How far the object actually got before the collector gave up. The server
186
+ // already knows the received chunk count; this is what the CLIENT believed,
187
+ // and a disagreement between the two is itself worth being able to see.
188
+ uploaded_chunk_count: z.number().int().nonnegative().optional(),
189
+ })
190
+ .strict();
191
+ export const RawEvidenceUploadAbortResponseSchema = z
192
+ .object({
193
+ ok: z.literal(true),
194
+ // `reason_recorded` is the ordinary answer: the reason landed on the
195
+ // still-open row, whose staged chunks stay resumable by the next `begin`.
196
+ // `aborted` means the reason was classified permanent and the row failed
197
+ // closed. `already_terminal` covers a row the server had already settled —
198
+ // a drain that ran first, or a duplicate abort after a retry. Reporting
199
+ // these back distinguishes "we recorded your reason" from "someone beat
200
+ // you to it", which a bare 200 would hide.
201
+ status: z.enum(["reason_recorded", "aborted", "already_terminal"]),
202
+ upload_id: NonEmptyStringSchema,
203
+ object_key: NonEmptyStringSchema,
204
+ status_reason: SafeLabelSchema,
205
+ // Two booleans because the underlying questions are not each other's
206
+ // negation, and one field would have to lie about half of them.
207
+ //
208
+ // `retryable` is `isRetryableUploadFailure`: is repeating this KNOWN to
209
+ // help? An unclassified reason answers no — refusing to promise something
210
+ // nobody has reasoned about.
211
+ //
212
+ // `will_reopen` is `!isPermanentUploadFailure`: is this row still open (or
213
+ // re-openable) for the next `begin`? An unclassified reason answers yes —
214
+ // refusing to abandon an object over a word it cannot read.
215
+ //
216
+ // So a composed transport label like `chunk_0_failed_http_500` comes back
217
+ // `retryable: false, will_reopen: true`, which is the honest pair: we are
218
+ // not claiming a retry succeeds, and we are not writing the row off.
219
+ retryable: z.boolean(),
220
+ will_reopen: z.boolean(),
221
+ })
222
+ .strict();
157
223
  /**
158
224
  * Codex session attribution report.
159
225
  *
@@ -45,6 +45,12 @@ const UPLOAD_FAILURE_CLASSES = {
45
45
  collection_failed: "transient",
46
46
  file_read_failed: "transient",
47
47
  git_diff_failed: "transient",
48
+ // `begin` opens a ledger row per object in a loop with no transaction, so a
49
+ // throw partway through leaves the earlier rows written while the client sees
50
+ // one 500 for the batch (BLI-2539: 12 such batches in production). Those rows
51
+ // now name themselves instead of going silent. Transient because the object
52
+ // was never offered a chance to upload — nothing about it was refused.
53
+ begin_batch_server_error: "transient",
48
54
  // The file itself is the problem, and it will be the same size and the same
49
55
  // shape on the next pass. Retrying is a promise nobody can keep.
50
56
  file_too_large: "deterministic",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@bli-cockpit/telemetry-core",
3
- "version": "0.1.18",
3
+ "version": "0.1.19",
4
4
  "private": false,
5
5
  "type": "module",
6
6
  "main": "./dist/index.js",