morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #5659] [Bug] Firmware publication timeout can crash the CLI before returning its timeout result #3429

New issue

Closed

opened 2026-10-31 00:40:22 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-31 00:40:22 +00:00

Owner

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

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

extract-firmware --publication-timeout-ms 1 --json can exit with an unhandled Node.js Readable error instead of returning its structured publication timeout. The failing call emits no JSON and leaves its newly created output directory behind.

Independent verification reproduced this through the unmodified CLI on Linux after successful extraction by a Python gzip stand-in. The stand-in actually decompresses the input and emits matching task, stat, hash and chunk records; it introduces no delay or injected failure. Real Unblob was not run. The submission recheck below inspected current source and the retained verification logs; it did not rerun the container.

Reproduction

Run from the source checkout root with locked dependencies installed and CLI built, on Linux with Node.js, Python 3, util-linux prlimit and procps ps. Use a container-local filesystem for the working directory. Binwalk is not required for extraction.

Create the isolated input and successful extractor stand-in:

work_dir="$(mktemp -d)"
S="$work_dir"
mkdir -p "$S/home" "$S/cfg" "$S/data" "$S/cache" "$S/state" "$S/tmp"
python3 - "$S/fw.bin" <<'PYTHON'
import gzip, pathlib, sys
pathlib.Path(sys.argv[1]).write_bytes(gzip.compress(b"firmware payload\n" * 200, mtime=0))
PYTHON
cat > "$S/unblob" <<'PYTHON'
#!/usr/bin/env python3
import gzip, hashlib, json, pathlib, sys
args=sys.argv[1:]
if args == ['--version']:
 print('26.6.4'); sys.exit(0)
source=pathlib.Path(args[-1]); raw=source.read_bytes()
out=pathlib.Path(args[args.index('--extract-dir')+1]); out.mkdir(parents=True)
child=out/'payload'; payload=gzip.decompress(raw); child.write_bytes(payload)
def task(path,depth,blob):
 return dict(path=str(path),depth=depth,blob_id=blob,is_multi_file=False)
def reports(path,data):
 return [dict(__typename__='StatReport',path=str(path),size=len(data),is_file=True,is_dir=False,is_link=False,link_target=None),dict(__typename__='HashReport',sha256=hashlib.sha256(data).hexdigest())]
ct=task(child,1,'gzip-1')
chunk=dict(__typename__='ChunkReport',id='gzip-1',start_offset=0,end_offset=len(raw),size=len(raw),handler_name='gzip',is_encrypted=False,extraction_reports=[])
records=[dict(task=task(source,0,''),reports=reports(source,raw)+[chunk],subtasks=[ct]),dict(task=ct,reports=reports(child,payload),subtasks=[])]
pathlib.Path(args[args.index('--report')+1]).write_text(json.dumps(records))
PYTHON
chmod +x "$S/unblob"
run_rea() {
  env -i PATH="$PATH" HOME="$S/home" XDG_CONFIG_HOME="$S/cfg" \
    XDG_DATA_HOME="$S/data" XDG_CACHE_HOME="$S/cache" \
    XDG_STATE_HOME="$S/state" TMPDIR="$S/tmp" REA_LOG_LEVEL=silent \
    REA_UNBLOB_COMMAND="$S/unblob" node scripts/rea.mjs "$@"
}

Check that normal extraction succeeds and publishes exactly the decompressed bytes:

run_rea extract-firmware "$S/fw.bin" "$S/control" \
  --publication-timeout-ms 60000 --json > "$S/control.json" 2> "$S/control.err"
python3 - "$S" <<'PYTHON'
import gzip, pathlib, sys
p=pathlib.Path(sys.argv[1])
assert (p/'control/payload').read_bytes() == gzip.decompress((p/'fw.bin').read_bytes())
PYTHON

Replay the intermittent deadline race with fresh absent destinations. Run the loop in a shell without errexit, since timeout calls intentionally exit 1:

mkdir -p "$S/runs"
i=1
while [ "$i" -le 60 ]; do
  run_rea extract-firmware "$S/fw.bin" "$S/out-$i" \
    --publication-timeout-ms 1 --json > "$S/runs/$i.json" 2> "$S/runs/$i.err"
  status=$?
  leftover=no
  [ -e "$S/out-$i" ] && leftover=yes
  printf '%s exit=%s stdout=%s leftover=%s\n' "$i" "$status" \
    "$(wc -c < "$S/runs/$i.json")" "$leftover"
  i=$((i+1))
done

In the independent container-local 1 ms run, attempt 28 of 60 crashed; the other 59 returned structured timeouts and removed their output trees. A separate shared-filesystem 1 ms run returned 40 structured timeouts in 40 calls without crashing. An additional container-local 60-call run using budgets 2+i%9 ms crashed seven times, returned 51 structured timeouts and completed twice. These are bounded samples, not estimated failure rates. The 60000 ms control succeeded and published all 3400 bytes matching independent Python gzip decompression.

Expected behavior

A deadline expiring during publication setup or copying should return structured provider_timeout JSON identifying phase publication and verified-file progress, and roll back failed uncommitted output. Accepted publication budgets include 1 ms.

Source contract at the verified baseline: rollback, valid budgets and timeout progress, and typed publication timeout construction.

Impact and scope

P2: some accepted short publication budgets terminate the operation without its timeout result or rollback. No loss of preexisting data or security boundary crossing was observed. A larger budget and fresh absent destination provide a demonstrated workaround: the 60000 ms control succeeded. Default-budget incidence, real Unblob, Linux x64 and MCP behavior were not tested. The source admits Linux without an architecture restriction; documentation describes Linux x64 as its verified lane.

REA version

rea-agents 6.7.0, source commit 5b676ba9f302228b44c28ab076525abed3e647c1 (runtime reproduction). Current origin/main 1629266e3c08c90fed6bba5383528af7986a12b7 is also 6.7.0: fetched and read all five cited source files; no changes to them since the baseline. No runtime rebuild or rerun was needed for this source recheck.

Runtime and platform

Reproduction: Node.js v24.18.0, Linux arm64 in Docker, real util-linux prlimit and procps ps, Python 3 gzip stand-in reporting version 26.6.4. Checkout mounted read-only; networking disabled. Submission host only: node --version v26.12.0, sw_vers -productVersion 27.0.1, uname -m arm64; no macOS firmware reproduction claimed.

Target and artifact context

Synthetic nonempty gzip input made from b"firmware payload\n" * 200; one regular decompressed payload file, 3400 bytes. No target execution. Each destination is initially absent and absolute, with an existing parent.

Interface

CLI

Earliest failure stage

Cleanup, cancellation, or lifecycle

Relevant output or evidence

Retained independent verification logs show the container-local 1 ms attempt 28 exited 1, wrote zero stdout bytes, and left its output directory present. The same signature appears in the additional 2–10 ms run:

throw er; // Unhandled 'error' event
ArtifactReaderFailure: Artifact file read cancelled
    at AbortSignal.onAbort (...)
    at Timeout._onTimeout (...)
Emitted 'error' event on Readable instance at:
reason: 'cancelled'
reason: DOMException [TimeoutError]: The operation was aborted due to timeout

The successful control returned extraction Evidence, empty stderr, and byte-identical decompressed output. The other 59 calls in the 1 ms container-local run returned provider_timeout, phase publication, with no leftover destination. These observations come from the independent verifier's retained logs and control checks, not a new submission-time execution.

Typed outcome or recovery expected

Always emit a valid JSON result. On timeout, return provider_timeout, publication phase and verified-file progress, then remove the uncommitted output tree. Successful calls must continue publishing the verified bytes. A proposed restoration check is to repeat the bounded loops and byte-equality control, then separately check the documented Linux x64 lane with real Unblob.

Analysis or suspected cause

Source-derived reasoning: FirmwareFiles.ts:179–185 creates the cancellation-bound source before passing it to the writer. SafeOutputTree.ts:178–218 awaits destination setup before attaching its async consumer. Meanwhile readFileHandleChunks.ts:98–108 can destroy the unread stream with a cancellation error. This leaves a gap in which the timeout can emit an unhandled error before the normal typed failure and rollback path settles. The stack agrees with this sequence. No bundled dependency is identified as the cause.

Additional context

Related #4176 / #4602 separated the analysis and publication deadlines; this report concerns an unhandled source-stream error after the separate publication budget starts. #4558 / #4563 concern cleanup-retry test expectations; #4475 and open #4493 concern descriptor-close ownership and readback cancellation, rather than this pre-consumption error event. Their descriptions do not cover this trigger and failure path.

Prepared with AI assistance using an independently verified reproduction. Last known good version is unknown. Real-provider conformance and a successful fix have not been established.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5659 ### 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 `extract-firmware --publication-timeout-ms 1 --json` can exit with an unhandled Node.js Readable error instead of returning its structured publication timeout. The failing call emits no JSON and leaves its newly created output directory behind. Independent verification reproduced this through the unmodified CLI on Linux after successful extraction by a Python gzip stand-in. The stand-in actually decompresses the input and emits matching task, stat, hash and chunk records; it introduces no delay or injected failure. Real Unblob was not run. The submission recheck below inspected current source and the retained verification logs; it did not rerun the container. ### Reproduction Run from the source checkout root with locked dependencies installed and CLI built, on Linux with Node.js, Python 3, util-linux `prlimit` and procps `ps`. Use a container-local filesystem for the working directory. Binwalk is not required for extraction. 1. Create the isolated input and successful extractor stand-in: ```sh work_dir="$(mktemp -d)" S="$work_dir" mkdir -p "$S/home" "$S/cfg" "$S/data" "$S/cache" "$S/state" "$S/tmp" python3 - "$S/fw.bin" <<'PYTHON' import gzip, pathlib, sys pathlib.Path(sys.argv[1]).write_bytes(gzip.compress(b"firmware payload\n" * 200, mtime=0)) PYTHON cat > "$S/unblob" <<'PYTHON' #!/usr/bin/env python3 import gzip, hashlib, json, pathlib, sys args=sys.argv[1:] if args == ['--version']: print('26.6.4'); sys.exit(0) source=pathlib.Path(args[-1]); raw=source.read_bytes() out=pathlib.Path(args[args.index('--extract-dir')+1]); out.mkdir(parents=True) child=out/'payload'; payload=gzip.decompress(raw); child.write_bytes(payload) def task(path,depth,blob): return dict(path=str(path),depth=depth,blob_id=blob,is_multi_file=False) def reports(path,data): return [dict(__typename__='StatReport',path=str(path),size=len(data),is_file=True,is_dir=False,is_link=False,link_target=None),dict(__typename__='HashReport',sha256=hashlib.sha256(data).hexdigest())] ct=task(child,1,'gzip-1') chunk=dict(__typename__='ChunkReport',id='gzip-1',start_offset=0,end_offset=len(raw),size=len(raw),handler_name='gzip',is_encrypted=False,extraction_reports=[]) records=[dict(task=task(source,0,''),reports=reports(source,raw)+[chunk],subtasks=[ct]),dict(task=ct,reports=reports(child,payload),subtasks=[])] pathlib.Path(args[args.index('--report')+1]).write_text(json.dumps(records)) PYTHON chmod +x "$S/unblob" run_rea() { env -i PATH="$PATH" HOME="$S/home" XDG_CONFIG_HOME="$S/cfg" \ XDG_DATA_HOME="$S/data" XDG_CACHE_HOME="$S/cache" \ XDG_STATE_HOME="$S/state" TMPDIR="$S/tmp" REA_LOG_LEVEL=silent \ REA_UNBLOB_COMMAND="$S/unblob" node scripts/rea.mjs "$@" } ``` 2. Check that normal extraction succeeds and publishes exactly the decompressed bytes: ```sh run_rea extract-firmware "$S/fw.bin" "$S/control" \ --publication-timeout-ms 60000 --json > "$S/control.json" 2> "$S/control.err" python3 - "$S" <<'PYTHON' import gzip, pathlib, sys p=pathlib.Path(sys.argv[1]) assert (p/'control/payload').read_bytes() == gzip.decompress((p/'fw.bin').read_bytes()) PYTHON ``` 3. Replay the intermittent deadline race with fresh absent destinations. Run the loop in a shell without `errexit`, since timeout calls intentionally exit 1: ```sh mkdir -p "$S/runs" i=1 while [ "$i" -le 60 ]; do run_rea extract-firmware "$S/fw.bin" "$S/out-$i" \ --publication-timeout-ms 1 --json > "$S/runs/$i.json" 2> "$S/runs/$i.err" status=$? leftover=no [ -e "$S/out-$i" ] && leftover=yes printf '%s exit=%s stdout=%s leftover=%s\n' "$i" "$status" \ "$(wc -c < "$S/runs/$i.json")" "$leftover" i=$((i+1)) done ``` In the independent container-local 1 ms run, attempt 28 of 60 crashed; the other 59 returned structured timeouts and removed their output trees. A separate shared-filesystem 1 ms run returned 40 structured timeouts in 40 calls without crashing. An additional container-local 60-call run using budgets `2+i%9` ms crashed seven times, returned 51 structured timeouts and completed twice. These are bounded samples, not estimated failure rates. The 60000 ms control succeeded and published all 3400 bytes matching independent Python gzip decompression. ### Expected behavior A deadline expiring during publication setup or copying should return structured `provider_timeout` JSON identifying phase `publication` and verified-file progress, and roll back failed uncommitted output. Accepted publication budgets include 1 ms. Source contract at the verified baseline: [rollback](https://github.com/morluto/rea/blob/5b676ba9f302228b44c28ab076525abed3e647c1/docs/firmware-analysis.md#L127-L131), [valid budgets and timeout progress](https://github.com/morluto/rea/blob/5b676ba9f302228b44c28ab076525abed3e647c1/docs/firmware-analysis.md#L161-L169), and [typed publication timeout construction](https://github.com/morluto/rea/blob/5b676ba9f302228b44c28ab076525abed3e647c1/src/firmware/FirmwareFailures.ts#L33-L60). ### Impact and scope P2: some accepted short publication budgets terminate the operation without its timeout result or rollback. No loss of preexisting data or security boundary crossing was observed. A larger budget and fresh absent destination provide a demonstrated workaround: the 60000 ms control succeeded. Default-budget incidence, real Unblob, Linux x64 and MCP behavior were not tested. The source admits Linux without an architecture restriction; documentation describes Linux x64 as its verified lane. ### REA version `rea-agents` 6.7.0, source commit `5b676ba9f302228b44c28ab076525abed3e647c1` (runtime reproduction). Current `origin/main` `1629266e3c08c90fed6bba5383528af7986a12b7` is also 6.7.0: fetched and read all five cited source files; no changes to them since the baseline. No runtime rebuild or rerun was needed for this source recheck. ### Runtime and platform Reproduction: Node.js v24.18.0, Linux arm64 in Docker, real util-linux `prlimit` and procps `ps`, Python 3 gzip stand-in reporting version 26.6.4. Checkout mounted read-only; networking disabled. Submission host only: `node --version` v26.12.0, `sw_vers -productVersion` 27.0.1, `uname -m` arm64; no macOS firmware reproduction claimed. ### Target and artifact context Synthetic nonempty gzip input made from `b"firmware payload\n" * 200`; one regular decompressed `payload` file, 3400 bytes. No target execution. Each destination is initially absent and absolute, with an existing parent. ### Interface CLI ### Earliest failure stage Cleanup, cancellation, or lifecycle ### Relevant output or evidence Retained independent verification logs show the container-local 1 ms attempt 28 exited 1, wrote zero stdout bytes, and left its output directory present. The same signature appears in the additional 2–10 ms run: ```text throw er; // Unhandled 'error' event ArtifactReaderFailure: Artifact file read cancelled at AbortSignal.onAbort (...) at Timeout._onTimeout (...) Emitted 'error' event on Readable instance at: reason: 'cancelled' reason: DOMException [TimeoutError]: The operation was aborted due to timeout ``` The successful control returned extraction Evidence, empty stderr, and byte-identical decompressed output. The other 59 calls in the 1 ms container-local run returned `provider_timeout`, phase `publication`, with no leftover destination. These observations come from the independent verifier's retained logs and control checks, not a new submission-time execution. ### Typed outcome or recovery expected Always emit a valid JSON result. On timeout, return `provider_timeout`, publication phase and verified-file progress, then remove the uncommitted output tree. Successful calls must continue publishing the verified bytes. A proposed restoration check is to repeat the bounded loops and byte-equality control, then separately check the documented Linux x64 lane with real Unblob. ### Analysis or suspected cause Source-derived reasoning: [FirmwareFiles.ts:179–185](https://github.com/morluto/rea/blob/5b676ba9f302228b44c28ab076525abed3e647c1/src/firmware/FirmwareFiles.ts#L179-L185) creates the cancellation-bound source before passing it to the writer. [SafeOutputTree.ts:178–218](https://github.com/morluto/rea/blob/5b676ba9f302228b44c28ab076525abed3e647c1/src/artifacts/SafeOutputTree.ts#L178-L218) awaits destination setup before attaching its async consumer. Meanwhile [readFileHandleChunks.ts:98–108](https://github.com/morluto/rea/blob/5b676ba9f302228b44c28ab076525abed3e647c1/src/filesystem/readFileHandleChunks.ts#L98-L108) can destroy the unread stream with a cancellation error. This leaves a gap in which the timeout can emit an unhandled error before the normal typed failure and rollback path settles. The stack agrees with this sequence. No bundled dependency is identified as the cause. ### Additional context Related #4176 / #4602 separated the analysis and publication deadlines; this report concerns an unhandled source-stream error after the separate publication budget starts. #4558 / #4563 concern cleanup-retry test expectations; #4475 and open #4493 concern descriptor-close ownership and readback cancellation, rather than this pre-consumption error event. Their descriptions do not cover this trigger and failure path. Prepared with AI assistance using an independently verified reproduction. Last known good version is unknown. Real-provider conformance and a successful fix have not been established.

bsakaguchi closed this issue

2026-10-31 00:40:22 +00:00

bsakaguchi commented

2026-10-31 00:40:23 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 20, 2026):

Cross-referencing with canonical issue #4558 ([Bug] firmwareIntegration publication cleanup-retry tests fail deterministically since 2d163c12). Both uncover stream handling, publication lifecycle, and unhandled timeout failure boundaries during firmware extraction. Cataloged under Cluster BU in consolidation tracker #4330.

@matbrgz commented on GitHub (Oct 20, 2026): Cross-referencing with canonical issue #4558 (`[Bug] firmwareIntegration publication cleanup-retry tests fail deterministically since 2d163c12`). Both uncover stream handling, publication lifecycle, and unhandled timeout failure boundaries during firmware extraction. Cataloged under Cluster BU in consolidation tracker #4330.

bsakaguchi commented

2026-10-31 00:40:23 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 20, 2026):

TL;DR: This still happens on main on Linux. With a publication budget of 2 to 10 ms, the CLI sometimes crashes with an unhandled Readable error. It prints no JSON and leaves the output folder behind.

Checked on main dceefa22c with a gzip stand-in for Unblob, written like the one in the report. Each call used a fresh absent output folder. The budgets were 2 + i % 9 ms, so 2 to 10 ms, as in the report's extra run.

Node	Calls	Crashed (exit 1, empty stdout, folder left)	Returned `provider_timeout`	Finished
22.23.1	120	15	100	5
24.18.0	120	11	71	38
26.11.1	120	8	71	41

Every crash printed Unhandled 'error' event and ArtifactReaderFailure: Artifact file read cancelled. The cause was a TimeoutError, like the report.
With a 1 ms budget on Node 24.18.0, 260 calls gave 260 structured timeouts and no crash. The report saw 1 crash in 60 on a container.
The 60,000 ms control on each Node exited 0 and the output matched the gzip bytes (3,400 bytes).
These are small samples, not failure rates. The timing differs by box.

Separate note: in some timeout runs (16 on Node 24, 27 on Node 22, 15 on Node 26) the output folder stayed. It held the full 3,400-byte payload. The message said "Extraction already completed." I did not check if that is meant to happen.

Not run

Real Unblob, Linux x64 lane, MCP, default budget, and any fix.

Thanks, coygeek, for the detailed report and the loop.

Commands

REA_UNBLOB_COMMAND=<stand-in> REA_LOG_LEVEL=silent <node> scripts/rea.mjs extract-firmware <fw.bin> <fresh-dir> --publication-timeout-ms <ms> --json

The loop ran in a Python script, not a shell loop. Each call had an isolated HOME, XDG and TMPDIR under /tmp. Crash stderr, trimmed:

node:events:487
      throw er; // Unhandled 'error' event
ArtifactReaderFailure: Artifact file read cancelled
    at AbortSignal.onAbort (.../readArtifactFileChunks-....js)
    at Timeout._onTimeout (node:internal/abort_controller)
Emitted 'error' event on Readable instance at:
  reason: 'cancelled'

Test setup

Box: Nobara 44 (Fedora 44 base), Linux 7.2.11
CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
RAM: 32 GB DDR4-3600
Node: 22.23.1, 24.18.0, 26.11.1
Head: dceefa22c
Other: output on a tmpfs /tmp; another job shared the box during the runs

🤖 Written and tested with Claude Code (Sonnet 5.5, verified by Opus 5.5), posted with my OK 🦊

@CassieFox23 commented on GitHub (Oct 20, 2026): **TL;DR:** This still happens on main on Linux. With a publication budget of 2 to 10 ms, the CLI sometimes crashes with an unhandled Readable error. It prints no JSON and leaves the output folder behind. Checked on main dceefa22c with a gzip stand-in for Unblob, written like the one in the report. Each call used a fresh absent output folder. The budgets were `2 + i % 9` ms, so 2 to 10 ms, as in the report's extra run. | Node | Calls | Crashed (exit 1, empty stdout, folder left) | Returned `provider_timeout` | Finished | | --- | --- | --- | --- | --- | | 22.23.1 | 120 | 15 | 100 | 5 | | 24.18.0 | 120 | 11 | 71 | 38 | | 26.11.1 | 120 | 8 | 71 | 41 | - Every crash printed `Unhandled 'error' event` and `ArtifactReaderFailure: Artifact file read cancelled`. The cause was a `TimeoutError`, like the report. - With a 1 ms budget on Node 24.18.0, 260 calls gave 260 structured timeouts and no crash. The report saw 1 crash in 60 on a container. - The 60,000 ms control on each Node exited 0 and the output matched the gzip bytes (3,400 bytes). - These are small samples, not failure rates. The timing differs by box. Separate note: in some timeout runs (16 on Node 24, 27 on Node 22, 15 on Node 26) the output folder stayed. It held the full 3,400-byte payload. The message said "Extraction already completed." I did not check if that is meant to happen. ### Not run - Real Unblob, Linux x64 lane, MCP, default budget, and any fix. Thanks, coygeek, for the detailed report and the loop. <details> <summary>Commands</summary> ```sh REA_UNBLOB_COMMAND=<stand-in> REA_LOG_LEVEL=silent <node> scripts/rea.mjs extract-firmware <fw.bin> <fresh-dir> --publication-timeout-ms <ms> --json ``` The loop ran in a Python script, not a shell loop. Each call had an isolated HOME, XDG and TMPDIR under /tmp. Crash stderr, trimmed: ```text node:events:487 throw er; // Unhandled 'error' event ArtifactReaderFailure: Artifact file read cancelled at AbortSignal.onAbort (.../readArtifactFileChunks-....js) at Timeout._onTimeout (node:internal/abort_controller) Emitted 'error' event on Readable instance at: reason: 'cancelled' ``` </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.11 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - RAM: 32 GB DDR4-3600 - Node: 22.23.1, 24.18.0, 26.11.1 - Head: dceefa22c - Other: output on a tmpfs /tmp; another job shared the box during the runs </details> 🤖 Written and tested with Claude Code (Sonnet 5.5, verified by Opus 5.5), posted with my OK 🦊

bsakaguchi commented

2026-10-31 00:40:24 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 24, 2026):

Checked the reported fix on main at d87e73f2db.

The firmware publisher now passes a lazy outer Readable to the tree and creates the abort-bound descriptor stream only when consumption begins. This removes the exact pre-consumption error-emission gap identified in the report. Its deterministic regression aborts at tree.write handoff, yields an event-loop turn with no consumer, then checks a typed cancellation with exact reason, rollback and unchanged input.

Implementation: FirmwareFiles.ts, firmwareReportFiles.test.ts.

The relevant regression checks in firmwareReportFiles.test.ts passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

@coygeek commented on GitHub (Oct 24, 2026): Checked the reported fix on `main` at d87e73f2db50be72d33a4b3c7199af35518b441c. The firmware publisher now passes a lazy outer Readable to the tree and creates the abort-bound descriptor stream only when consumption begins. This removes the exact pre-consumption error-emission gap identified in the report. Its deterministic regression aborts at tree.write handoff, yields an event-loop turn with no consumer, then checks a typed cancellation with exact reason, rollback and unchanged input. Implementation: [FirmwareFiles.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/firmware/FirmwareFiles.ts#L215), [firmwareReportFiles.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/tests/boundary/firmware/firmwareReportFiles.test.ts#L241). The relevant regression checks in [firmwareReportFiles.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/tests/boundary/firmware/firmwareReportFiles.test.ts) passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

bsakaguchi referenced this issue

2026-10-31 01:09:04 +00:00

[PR #3429] feat(binary): recognize XEX2 and PowerPC PE basefiles #5740

bsakaguchi referenced this issue

2026-11-01 21:11:07 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425