@bli-cockpit/telemetry-core 0.1.24 → 0.1.25
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.
- package/dist/upload-failure-class.js +11 -0
- package/package.json +1 -1
|
@@ -149,6 +149,17 @@ const UPLOAD_FAILURE_CLASSES = {
|
|
|
149
149
|
// The file itself is the problem, and it will be the same size and the same
|
|
150
150
|
// shape on the next pass. Retrying is a promise nobody can keep.
|
|
151
151
|
file_too_large: "deterministic",
|
|
152
|
+
// A declared image above IMAGE_EVIDENCE_MAX_VALIDATION_BYTES (BLI-3067). The
|
|
153
|
+
// commit route deliberately KEEPS the staged chunks for these so that raising
|
|
154
|
+
// the bound turns the identical row into a commit that works — and
|
|
155
|
+
// `docs/runbooks/cockpit-stuck-evidence-uploads.md` has always documented it
|
|
156
|
+
// as deterministic. The entry was missing here, so it classified `unknown`,
|
|
157
|
+
// `isPermanentUploadFailure` answered false, and `begin`'s terminal-failure
|
|
158
|
+
// guard fell through to the reset that deletes those very chunk receipts —
|
|
159
|
+
// destroying the retained staging on the next sync and re-uploading the same
|
|
160
|
+
// oversized image forever. That is the BLI-2528 loop reappearing inside the
|
|
161
|
+
// code written to end it (BLI-3408).
|
|
162
|
+
image_too_large_to_validate: "deterministic",
|
|
152
163
|
// Storage looked at the finished object and said no. The bytes are already
|
|
153
164
|
// final and content-addressed, so the next attempt presents the identical
|
|
154
165
|
// object to the identical rule (BLI-2528). Retrying these is what let 76
|