[GH-ISSUE #1855] [Bug] Firmware execution failure recommends retry despite retryable=false #629

New issue

Closed

opened 2026-10-15 18:26:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:46 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1855

Before submitting

I searched open and closed issues and pull requests for related work.
I removed credentials, private paths, and sensitive target data.

Area

Provider or capability discovery; Evidence, artifacts, or reconstruction.

Observed behavior

A firmware inspection unreadable_output / execution_failure reports that its complete expected report was not produced, while its remediation says Retry once and its tagged outcome declares retryable=false.

Reproduction

Run inspect_firmware_regions with a configured report-producing command whose expected report is not published.
Inspect both the tagged retryability and human-readable remediation of the resulting execution failure.

Expected behavior

Retryability and remediation describe the same supported recovery. Preserve exit/signal/report-publication and capacity evidence rather than guessing a parser failure.

Impact and scope

The contradictory guidance can trigger an unchanged retry of an explicitly non-retryable operation. The observed missing-report root cause is not established and is separate from this diagnostic inconsistency.

REA version

Observed at source revision 97c0348e6bef62bb7183d52bcebea8299c5b3afe; current-main reproduction is part of the investigation.

Runtime and platform

Linux x86_64, Node.js 24.18.0. Heavy operations used a one-CPU, 3-GiB process-tree limit.

Interface

MCP; the shared CLI workflow should be verified where applicable.

Earliest failure stage

Transport or result projection; typed error/diagnostic construction.

Relevant output or evidence

unreadable_output, execution_failure, retryable=false, remediation containing Retry once; no complete report produced.

Analysis or suspected cause

Find the error/remediation owner and model the actual recovery decision once. Preserve truthful unknown causes and do not reinterpret resource symptoms as malformed input.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1855 ### Before submitting - [x] I searched open and closed issues and pull requests for related work. - [x] I removed credentials, private paths, and sensitive target data. ### Area Provider or capability discovery; Evidence, artifacts, or reconstruction. ### Observed behavior A firmware inspection `unreadable_output` / `execution_failure` reports that its complete expected report was not produced, while its remediation says `Retry once` and its tagged outcome declares `retryable=false`. ### Reproduction 1. Run `inspect_firmware_regions` with a configured report-producing command whose expected report is not published. 2. Inspect both the tagged retryability and human-readable remediation of the resulting execution failure. ### Expected behavior Retryability and remediation describe the same supported recovery. Preserve exit/signal/report-publication and capacity evidence rather than guessing a parser failure. ### Impact and scope The contradictory guidance can trigger an unchanged retry of an explicitly non-retryable operation. The observed missing-report root cause is not established and is separate from this diagnostic inconsistency. ### REA version Observed at source revision `97c0348e6bef62bb7183d52bcebea8299c5b3afe`; current-main reproduction is part of the investigation. ### Runtime and platform Linux x86_64, Node.js 24.18.0. Heavy operations used a one-CPU, 3-GiB process-tree limit. ### Interface MCP; the shared CLI workflow should be verified where applicable. ### Earliest failure stage Transport or result projection; typed error/diagnostic construction. ### Relevant output or evidence `unreadable_output`, `execution_failure`, `retryable=false`, remediation containing `Retry once`; no complete report produced. ### Analysis or suspected cause Find the error/remediation owner and model the actual recovery decision once. Preserve truthful unknown causes and do not reinterpret resource symptoms as malformed input.

bsakaguchi

2026-10-15 18:26:46 +00:00