[GH-ISSUE #7347] [Bug] ASAR inspection limit errors omit the parsed required header size #4366

Open
opened 2026-10-31 00:49:15 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @coygeek on GitHub (Oct 27, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7347

Before submitting

  • I searched the open and closed issues for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

inspect-artifact refuses valid ASAR archives whose headers exceed a configured admission, but its JSON error omits details.limit.required_value even though classification has parsed that size. I observed this with a 20-byte header at limit 19 and a 24-byte header at limit 23. Both errors preserve the setting, effective value, source, bounds and units. Both archives inspect successfully at the default admission and when the admission equals their header size.

Reproduction

Use an already built source checkout at the revision below and Node 24.22.1. The following creates the exact archive bytes used in my local probe and repeats its six public CLI invocations; the probe invoked them sequentially from Python with an isolated environment.

W="$(mktemp -d)"
mkdir -p "$W/home" "$W/tmp"
python3 - "$W" <<'PY'
import pathlib, struct, sys
root = pathlib.Path(sys.argv[1])
for size in (20, 24):
    text = b'{"files":{}}' + b' ' * (size - 20)
    archive = struct.pack('<IIII', 4, size, size - 4, len(text)) + text
    (root / f'header-{size}.asar').write_bytes(archive)
PY
for size in 20 24; do
  env -i HOME="$W/home" TMPDIR="$W/tmp" PATH="$PATH" \
    node scripts/rea.mjs inspect-artifact "$W/header-$size.asar" --format json
  printf 'default exit: %s\n' "$?"
  env -i HOME="$W/home" TMPDIR="$W/tmp" PATH="$PATH" \
    REA_ASAR_MAX_HEADER_BYTES="$((size - 1))" \
    node scripts/rea.mjs inspect-artifact "$W/header-$size.asar" --format json
  printf 'below-header exit: %s\n' "$?"
  env -i HOME="$W/home" TMPDIR="$W/tmp" PATH="$PATH" \
    REA_ASAR_MAX_HEADER_BYTES="$size" \
    node scripts/rea.mjs inspect-artifact "$W/header-$size.asar" --format json
  printf 'exact-header exit: %s\n' "$?"
done

For each archive, the default and exact-header commands exit 0 with normalized_result.subject.root_format: "asar" and normalized_result.coverage.status: "complete-within-substeps". Each below-header command exits 1 with code: "truncated", details.reason: "limit", and no required_value in details.limit. Each of these six cases ran once.

Expected behavior

The documented ASAR recovery contract supplies required bytes in details.limit when known. These archives have valid parsed header extents, so the refusals should report required_value: 20 and required_value: 24, respectively. The refusal itself and the configured admission remain appropriate.

Impact and scope

The observed effect is incomplete structured recovery metadata: a caller cannot learn the required admission from this error alone. The configured admission and successful inspection behavior work in the tested cases. NOT_ENOUGH_INFO: no failed direct retry, lost analysis result, production workload impact or affected-user frequency was established. I did not test headers above the default admission, MCP, extraction or JavaScript analysis.

REA version

REA 6.8.0, source revision ace4dbf36e.

Runtime and platform

Node v24.22.1; macOS, darwin arm64. Built CLI; no external analysis engine used.

Target and artifact context

Two synthetic ASAR archives with empty files tables: 28 bytes with a 20-byte header, and 32 bytes with a 24-byte header. The second adds four trailing JSON whitespace bytes. No application was executed.

Interface

CLI

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

  • Expected source: docs/design/limits-and-recovery.md:197 documents known required bytes in ASAR details.limit and the optional required_value field.
  • Failure source: the two executed below-header CLI results omit that field. Source inspection traces the retained extent through src/artifacts/AsarHeader.ts:254 and :312, the one-argument failure construction at src/artifacts/inventory/ArtifactGraphConstruction.ts:548, and conditional projection at src/artifacts/ArtifactOperationFailure.ts:39.
  • Evidence provenance: observed for CLI results; static source inspection explains the producing path and confirms that fetched upstream source retains it.
  • Local verification: reproduced, two refusing cases and four successful controls.
  • Reproduction completeness: complete.

Selected fields from the 20-byte-header refusal, with other fields omitted:

{
  "code": "truncated",
  "details": {
    "reason": "limit",
    "admission": "asar-header",
    "maximum_header_bytes": 19,
    "limit": {
      "setting": "asar.max_header_bytes",
      "effective_value": 19,
      "source": "setting",
      "unit": "bytes",
      "minimum": 1,
      "maximum": 268435456
    }
  }
}

Additional context

Restoration check: retain the two below-header refusals and include their respective details.limit.required_value values, 20 and 24; retain successful inspection at each exact header size. Merely admitting the archive or returning a fixed number does not restore the missing diagnostic contract. This is a proposed check, not an executed fix verification.

The open and closed issue search included complete related bodies and current discussion for #6176 and #6209. Those address configurability and effective-value/source reporting; neither reports the parsed required-size omission. #7049 introduces runtime recovery, but its report does not identify this omission. No matching report was found. Current upstream persistence was checked by source comparison only; a newer runtime was not built or executed. Last known good version: NOT_ENOUGH_INFO; none established.

Triage assessment

  • Impact level: undetermined
  • Assessment status: undetermined
  • Impact basis: The structured diagnostic contract fails, but the bounded probes show successful exact-limit recovery and establish no consequential downstream failure; P2 impact is therefore not established.
  • Workaround status: available
  • Workaround basis: When the header size is independently known, configuring that value permits inspection; this was observed at 20 and 24 bytes. It does not restore the missing field.
Originally created by @coygeek on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7347 ## Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Area Evidence, artifacts, or reconstruction ## Observed behavior `inspect-artifact` refuses valid ASAR archives whose headers exceed a configured admission, but its JSON error omits `details.limit.required_value` even though classification has parsed that size. I observed this with a 20-byte header at limit 19 and a 24-byte header at limit 23. Both errors preserve the setting, effective value, source, bounds and units. Both archives inspect successfully at the default admission and when the admission equals their header size. ## Reproduction Use an already built source checkout at the revision below and Node 24.22.1. The following creates the exact archive bytes used in my local probe and repeats its six public CLI invocations; the probe invoked them sequentially from Python with an isolated environment. ```sh W="$(mktemp -d)" mkdir -p "$W/home" "$W/tmp" python3 - "$W" <<'PY' import pathlib, struct, sys root = pathlib.Path(sys.argv[1]) for size in (20, 24): text = b'{"files":{}}' + b' ' * (size - 20) archive = struct.pack('<IIII', 4, size, size - 4, len(text)) + text (root / f'header-{size}.asar').write_bytes(archive) PY for size in 20 24; do env -i HOME="$W/home" TMPDIR="$W/tmp" PATH="$PATH" \ node scripts/rea.mjs inspect-artifact "$W/header-$size.asar" --format json printf 'default exit: %s\n' "$?" env -i HOME="$W/home" TMPDIR="$W/tmp" PATH="$PATH" \ REA_ASAR_MAX_HEADER_BYTES="$((size - 1))" \ node scripts/rea.mjs inspect-artifact "$W/header-$size.asar" --format json printf 'below-header exit: %s\n' "$?" env -i HOME="$W/home" TMPDIR="$W/tmp" PATH="$PATH" \ REA_ASAR_MAX_HEADER_BYTES="$size" \ node scripts/rea.mjs inspect-artifact "$W/header-$size.asar" --format json printf 'exact-header exit: %s\n' "$?" done ``` For each archive, the default and exact-header commands exit 0 with `normalized_result.subject.root_format: "asar"` and `normalized_result.coverage.status: "complete-within-substeps"`. Each below-header command exits 1 with `code: "truncated"`, `details.reason: "limit"`, and no `required_value` in `details.limit`. Each of these six cases ran once. ## Expected behavior The documented ASAR recovery contract supplies required bytes in `details.limit` when known. These archives have valid parsed header extents, so the refusals should report `required_value: 20` and `required_value: 24`, respectively. The refusal itself and the configured admission remain appropriate. ## Impact and scope The observed effect is incomplete structured recovery metadata: a caller cannot learn the required admission from this error alone. The configured admission and successful inspection behavior work in the tested cases. NOT_ENOUGH_INFO: no failed direct retry, lost analysis result, production workload impact or affected-user frequency was established. I did not test headers above the default admission, MCP, extraction or JavaScript analysis. ## REA version REA 6.8.0, source revision ace4dbf36e8c8f36a0e192aff9a11484ed428358. ## Runtime and platform Node v24.22.1; macOS, darwin arm64. Built CLI; no external analysis engine used. ## Target and artifact context Two synthetic ASAR archives with empty files tables: 28 bytes with a 20-byte header, and 32 bytes with a 24-byte header. The second adds four trailing JSON whitespace bytes. No application was executed. ## Interface CLI ## Earliest failure stage Artifact or evidence registration ## Relevant output or evidence - Expected source: `docs/design/limits-and-recovery.md:197` documents known required bytes in ASAR `details.limit` and the optional `required_value` field. - Failure source: the two executed below-header CLI results omit that field. Source inspection traces the retained extent through `src/artifacts/AsarHeader.ts:254` and `:312`, the one-argument failure construction at `src/artifacts/inventory/ArtifactGraphConstruction.ts:548`, and conditional projection at `src/artifacts/ArtifactOperationFailure.ts:39`. - Evidence provenance: observed for CLI results; static source inspection explains the producing path and confirms that fetched upstream source retains it. - Local verification: reproduced, two refusing cases and four successful controls. - Reproduction completeness: complete. Selected fields from the 20-byte-header refusal, with other fields omitted: ```json { "code": "truncated", "details": { "reason": "limit", "admission": "asar-header", "maximum_header_bytes": 19, "limit": { "setting": "asar.max_header_bytes", "effective_value": 19, "source": "setting", "unit": "bytes", "minimum": 1, "maximum": 268435456 } } } ``` ## Additional context Restoration check: retain the two below-header refusals and include their respective `details.limit.required_value` values, 20 and 24; retain successful inspection at each exact header size. Merely admitting the archive or returning a fixed number does not restore the missing diagnostic contract. This is a proposed check, not an executed fix verification. The open and closed issue search included complete related bodies and current discussion for #6176 and #6209. Those address configurability and effective-value/source reporting; neither reports the parsed required-size omission. #7049 introduces runtime recovery, but its report does not identify this omission. No matching report was found. Current upstream persistence was checked by source comparison only; a newer runtime was not built or executed. Last known good version: NOT_ENOUGH_INFO; none established. ## Triage assessment - Impact level: undetermined - Assessment status: undetermined - Impact basis: The structured diagnostic contract fails, but the bounded probes show successful exact-limit recovery and establish no consequential downstream failure; P2 impact is therefore not established. - Workaround status: available - Workaround basis: When the header size is independently known, configuring that value permits inspection; this was observed at 20 and 24 bytes. It does not restore the missing field.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#4366
No description provided.