[GH-ISSUE #1501] fix(firmware): return a completed extraction when workspace teardown fails #511

New issue

Closed

opened 2026-10-15 18:25:44 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:25:44 +00:00

Owner

Originally created by @cursor[bot] on GitHub (Oct 10, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1501

TL;DR: A firmware extraction that finishes, then fails while closing its private workspace, is returned only as a cleanup error. The provider then rejects every later firmware operation, including a different engine.

One-shot analysis elsewhere keeps the completed evidence beside the cleanup failure. This provider replaces the outcome and latches the process.

Area

Firmware analysis

Observed behavior

FirmwareProvider.#execute in src/firmware/FirmwareProvider.ts runs binwalk or unblob in a new private root. If the operation's outcome is successful and root.close() throws:

#cleanupFailure is set to a ProviderCleanupError
previous_result is stored on that error's diagnostics
the function return err(this.#cleanupFailure)

The caller sees a failed result. directAnalysisCleanupFailure in src/application/DirectAnalysisCleanup.ts is the other policy: "Keep the primary CLI failure or completed Evidence alongside cleanup failure."

The next call, of either inspect_firmware_regions or extract_firmware, returns that same error immediately, before a new root is created. The two operations use different engines and different workspaces. The comment on the latch says not to remove a workspace while process ownership is uncertain. The latch also refuses work that does not touch that workspace.

Expected behavior

A completed extraction should still be returned, with the cleanup failure attached and the leaked root named, the same way one-shot analysis keeps completed evidence. A later operation should be allowed to create its own root. The leaked root stays owned and is not deleted.

Where

src/firmware/FirmwareProvider.ts — #execute, #cleanupFailure
src/application/DirectAnalysisCleanup.ts — directAnalysisCleanupFailure

Originally created by @cursor[bot] on GitHub (Oct 10, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1501 **TL;DR:** A firmware extraction that finishes, then fails while closing its private workspace, is returned only as a cleanup error. The provider then rejects every later firmware operation, including a different engine. One-shot analysis elsewhere keeps the completed evidence beside the cleanup failure. This provider replaces the outcome and latches the process. ### Area Firmware analysis ### Observed behavior `FirmwareProvider.#execute` in `src/firmware/FirmwareProvider.ts` runs binwalk or unblob in a new private root. If the operation's `outcome` is successful and `root.close()` throws: - `#cleanupFailure` is set to a `ProviderCleanupError` - `previous_result` is stored on that error's diagnostics - the function `return err(this.#cleanupFailure)` The caller sees a failed result. `directAnalysisCleanupFailure` in `src/application/DirectAnalysisCleanup.ts` is the other policy: "Keep the primary CLI failure or completed Evidence alongside cleanup failure." The next call, of either `inspect_firmware_regions` or `extract_firmware`, returns that same error immediately, before a new root is created. The two operations use different engines and different workspaces. The comment on the latch says not to remove a workspace while process ownership is uncertain. The latch also refuses work that does not touch that workspace. ### Expected behavior A completed extraction should still be returned, with the cleanup failure attached and the leaked root named, the same way one-shot analysis keeps completed evidence. A later operation should be allowed to create its own root. The leaked root stays owned and is not deleted. ### Where - `src/firmware/FirmwareProvider.ts` — `#execute`, `#cleanupFailure` - `src/application/DirectAnalysisCleanup.ts` — `directAnalysisCleanupFailure`

bsakaguchi

2026-10-15 18:25:44 +00:00

closed this issue
added the
area: providers

bug

P2: medium
labels

bsakaguchi commented

2026-10-15 18:25:45 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 10, 2026):

Follow-up on current main 0d899783: the completed extraction is now retained as partial_observation, but a filesystem-only workspace removal failure still blocks every later request through #retryCleanup(). The existing independent-helper test does not cover this same-provider transition. I am checking that boundary with a real subprocess/filesystem failure and preserving the fail-closed behavior when process ownership is still unverified.

The current firmware integration suite also has a stale expectation that another process launches after unverified worker cleanup; it fails on the current fail-closed implementation. I will correct that regression alongside the recovery checks.

@N0zoM1z0 commented on GitHub (Oct 10, 2026): Follow-up on current main `0d899783`: the completed extraction is now retained as `partial_observation`, but a filesystem-only workspace removal failure still blocks every later request through `#retryCleanup()`. The existing independent-helper test does not cover this same-provider transition. I am checking that boundary with a real subprocess/filesystem failure and preserving the fail-closed behavior when process ownership is still unverified. The current firmware integration suite also has a stale expectation that another process launches after unverified worker cleanup; it fails on the current fail-closed implementation. I will correct that regression alongside the recovery checks.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:13:35 +00:00

[PR #511] [MERGED] fix(javascript): isolate lexical loop bindings #2035