[PR #6175] [MERGED] fix(model): keep host I/O failures distinct from unavailable model targets #7184

Closed
opened 2026-11-01 21:45:58 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6175
Author: @amyanger
Created: 10/21/2026
Status: ✅ Merged
Merged: 10/22/2026
Merged by: @morluto

Base: main ← Head: fix/6004-model-host-io-errors


📝 Commits (1)

  • 9adee5c fix(model): keep host I/O failures distinct from unavailable model targets

📊 Changes

3 files changed (+157 additions, -2 deletions)

View changed files

📝 docs/model-artifacts.md (+4 -1)
📝 src/model/ModelArtifactProvider.ts (+16 -1)
➕ tests/process-global/modelHostReadFailure.test.ts (+137 -0)

📄 Description

Summary

inspect_model_artifact reported host I/O and resource failures on a valid selected model (for example EMFILE at open or EIO at header read) as target_unavailable / unavailable, with advice to check that the path exists and is readable. Those failures now reach the provider's existing execution_failure fallback with the selected path and the original reason. Errors about the selected path itself keep their target refusal.

Fixes #6004

Problem and expected behavior

ModelArtifactProvider handled its typed and permission cases, then turned every remaining Error with a code property into BinaryTargetError. Any errno, including descriptor exhaustion or a device read error, was reported as a selected-path problem. The issue's expected behavior is that host failures stay distinct from selected-path or format refusal, while missing-path, access-denied and format refusals keep their own semantics.

Change and scope

The final coded-error branch now applies only to codes that describe the selected path: ENOENT, ENOTDIR, ELOOP, ENAMETOOLONG (the same set GoBinaryProvider's failureForPrimary treats as path errors), plus the codes RegularFile itself raises for the selected file: EISDIR and ENOTFILE (NonRegularFileReadError) and ESTALE (RegularFileChangedError). Every other coded error falls through to the ProviderAdapterError branch that uncoded errors already used. Permission (EACCES/EPERM), format, cancellation, integrity, limit, cleanup and partial-observation handling are unchanged.

docs/model-artifacts.md gains one sentence describing the split.

Not included: GpuCodeObjectsProvider has the same catch-all branch and is left for its own issue. The binary-target resolver's own stat classification (classifyBinaryTargetFilesystemFailure) also maps EIO to target_unavailable, and the issue lists other producers (#5953, #5970, #5991, #5997). Those are separate boundaries and are left alone.

Contribution scope: ordinary fix within an existing boundary, no maintainer scope decision needed.

Contract and boundary impact

  • Semantic owner and earliest changed stage: ModelArtifactProvider failure mapping, after file admission and header read.
  • Contribution scope fit and linked maintainer decision: not applicable, error classification only.
  • CLI and MCP/tool-catalog contract: no schema change. Non-path host errors from model inspection now project as execution_failure with details.provider_id and details.diagnostics.{path,reason} instead of target_unavailable.
  • Provider, bridge, target-format, or platform compatibility: none. Path errno values were checked on macOS (below); Linux uses the same codes for these cases per the reviewer's source trace, not executed.
  • Evidence, artifact, provenance, or reconstruction contract: none. Cleanup-failure wrapping and partial-observation retention run after the error is chosen, so they apply to the new branch unchanged.
  • Target selection, authority, upstream behavior, and cleanup details: unchanged.
  • Generated metadata, package, or installation impact: none.

Expected effects:

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

  • Tests added or updated: tests/process-global/modelHostReadFailure.test.ts. Through the production MCP registration and in-memory transport, for both GGUF and safetensors, it injects EMFILE at open and EIO at the first read and expects execution_failure with path and reason, no path advice, closed handles and a successful inspection after each fault. It also injects each of the seven selected-path codes and inspects a really missing path, and expects target_unavailable for all of them. It lives in tests/process-global/ because it mocks node:fs/promises, per docs/testing.md.
  • Base reproduction (executed): with the production change stashed on base 01788bac8, npm run test:focused -- tests/process-global/modelHostReadFailure.test.ts: 2 failed, both expected { code: 'target_unavailable', … } to match object { code: 'execution_failure', … } for the EMFILE open fault.
  • Mutation checks (executed, npm run test:focused on the new and boundary model tests): removing the code filter, removing each of the seven codes individually, and emptying the set each made the run fail with assertion errors (9 of 9 mutants caught).
  • User-visible CLI output (executed, built CLI node scripts/rea.mjs inspect-model-artifact <path> --json on macOS): a missing file, a directory, a path under a regular file, a symlink and a FIFO all still return target_unavailable / unavailable.
  • Remaining proof gaps: host faults are injected through a mocked node:fs/promises; real descriptor exhaustion and device failures were not produced. Windows was not run (there a locked file's EBUSY would now be execution_failure). If a socket path disappears between the failed open and nonRegularOpenFailure's follow-up lstat, the raw ENXIO/EOPNOTSUPP now reports execution_failure instead of target_unavailable; this is a narrow race and was left as is.

For evidence-bearing changes:

  • Observed, derived, and inferred claims remain distinguishable.
  • Artifact identity, source provenance, and failed attempts remain preserved.
  • Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

Run on macOS 27 arm64, Node from .nvmrc, base 01788bac8. After a rebase onto green main 166fb0820, the focused tests, check:fast, test:changed and docs:check were run again and passed.

  • npm run test:focused -- tests/process-global/modelHostReadFailure.test.ts tests/boundary/model/modelArtifact.test.ts tests/acceptance/modelArtifactCli.test.ts: 3 files, 76 tests passed.
  • Same new test with the production change stashed: 2 failed (base reproduction above).
  • Mutation run over the new and boundary model tests: 9 of 9 mutants failed with assertion errors.
  • npm run check:fast: 2 of 2 tasks successful.
  • npm run test:changed -- --base 01788bac8: 2 files, 3 tests passed. Rerun after the rebase with --base 166fb0820: 3 files, 4 tests passed.
  • npm run verify:test-discovery: discovered all 1930 test files exactly once.
  • npm run check: exit 0, module boundaries checked in 2483 source files, architecture guards passed across 1727 source files.
  • node scripts/rea.mjs inspect-model-artifact <path> --json after npm run build:cached: missing file, directory, path under a regular file, symlink and FIFO each returned target_unavailable / unavailable.
  • Independent adversarial review (read-only, own worktree): no blocking findings. It traced every coded error that can reach the branch, confirmed on macOS that symlink, symlink loop, directory, FIFO, Unix socket, missing file, ENOTDIR, a 300-character name and /dev/null still produce BinaryTargetError, and confirmed no test, doc or contract expects target_unavailable for non-path host errors. It reported the socket race listed under proof gaps.
  • npm run docs:check: exit 0.
  • Automated code review (high effort) on the working-tree diff, each finding checked by hand:
    • The open-stage handle assertion was vacuous when no handle was opened. Fixed: the read stage now also asserts a handle was captured.
    • The public error split was undocumented. Fixed: one sentence in docs/model-artifacts.md.
    • It claimed the new execution_failure is retryable. Not so: the test now pins retryable: false, matching the issue's uncoded control.
    • src/gpu/GpuCodeObjectsProvider.ts:181 has the same catch-all coded-error branch. Confirmed, but outside this issue; left for a separate issue.
    • Suggestions not taken: remapping ESTALE (RegularFileChangedError) to the artifact-changed error and rewording ELOOP (both unchanged from base), a typed resource error for EMFILE/ENFILE, and moving classification into the shared BinaryTargetResolver classifier (which would change other callers). Each is a separate behavior change.
    • After these changes the base run, mutation run, focused tests, check:fast, test:changed, docs:check and npm run check were all rerun with the results above.

Compatibility, safety, and release

  • Breaking changes or migration steps: none. Callers that branched on target_unavailable for non-path host errors from model inspection now see execution_failure, which is the outcome the issue asks for.
  • Real Hopper/Ghidra, browser, or OS coverage: not applicable. The model provider parses local files directly; the real provider was exercised through the built CLI on macOS 27 arm64.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: no new reads, paths or processes. Reported reasons are the same host messages that were already returned.

Author readiness

Human owner: @amyanger

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/6175 **Author:** [@amyanger](https://github.com/amyanger) **Created:** 10/21/2026 **Status:** ✅ Merged **Merged:** 10/22/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/6004-model-host-io-errors` --- ### 📝 Commits (1) - [`9adee5c`](https://github.com/morluto/rea/commit/9adee5ca98cee40f57aae80ce491faf33ec05e06) fix(model): keep host I/O failures distinct from unavailable model targets ### 📊 Changes **3 files changed** (+157 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `docs/model-artifacts.md` (+4 -1) 📝 `src/model/ModelArtifactProvider.ts` (+16 -1) ➕ `tests/process-global/modelHostReadFailure.test.ts` (+137 -0) </details> ### 📄 Description ## Summary `inspect_model_artifact` reported host I/O and resource failures on a valid selected model (for example `EMFILE` at open or `EIO` at header read) as `target_unavailable` / `unavailable`, with advice to check that the path exists and is readable. Those failures now reach the provider's existing `execution_failure` fallback with the selected path and the original reason. Errors about the selected path itself keep their target refusal. Fixes #6004 ## Problem and expected behavior `ModelArtifactProvider` handled its typed and permission cases, then turned every remaining `Error` with a `code` property into `BinaryTargetError`. Any errno, including descriptor exhaustion or a device read error, was reported as a selected-path problem. The issue's expected behavior is that host failures stay distinct from selected-path or format refusal, while missing-path, access-denied and format refusals keep their own semantics. ## Change and scope The final coded-error branch now applies only to codes that describe the selected path: `ENOENT`, `ENOTDIR`, `ELOOP`, `ENAMETOOLONG` (the same set `GoBinaryProvider`'s `failureForPrimary` treats as path errors), plus the codes `RegularFile` itself raises for the selected file: `EISDIR` and `ENOTFILE` (`NonRegularFileReadError`) and `ESTALE` (`RegularFileChangedError`). Every other coded error falls through to the `ProviderAdapterError` branch that uncoded errors already used. Permission (`EACCES`/`EPERM`), format, cancellation, integrity, limit, cleanup and partial-observation handling are unchanged. `docs/model-artifacts.md` gains one sentence describing the split. Not included: `GpuCodeObjectsProvider` has the same catch-all branch and is left for its own issue. The binary-target resolver's own stat classification (`classifyBinaryTargetFilesystemFailure`) also maps `EIO` to `target_unavailable`, and the issue lists other producers (#5953, #5970, #5991, #5997). Those are separate boundaries and are left alone. Contribution scope: ordinary fix within an existing boundary, no maintainer scope decision needed. ## Contract and boundary impact - Semantic owner and earliest changed stage: `ModelArtifactProvider` failure mapping, after file admission and header read. - Contribution scope fit and linked maintainer decision: not applicable, error classification only. - CLI and MCP/tool-catalog contract: no schema change. Non-path host errors from model inspection now project as `execution_failure` with `details.provider_id` and `details.diagnostics.{path,reason}` instead of `target_unavailable`. - Provider, bridge, target-format, or platform compatibility: none. Path errno values were checked on macOS (below); Linux uses the same codes for these cases per the reviewer's source trace, not executed. - Evidence, artifact, provenance, or reconstruction contract: none. Cleanup-failure wrapping and partial-observation retention run after the error is chosen, so they apply to the new branch unchanged. - Target selection, authority, upstream behavior, and cleanup details: unchanged. - Generated metadata, package, or installation impact: none. Expected effects: - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: `tests/process-global/modelHostReadFailure.test.ts`. Through the production MCP registration and in-memory transport, for both GGUF and safetensors, it injects `EMFILE` at open and `EIO` at the first read and expects `execution_failure` with path and reason, no path advice, closed handles and a successful inspection after each fault. It also injects each of the seven selected-path codes and inspects a really missing path, and expects `target_unavailable` for all of them. It lives in `tests/process-global/` because it mocks `node:fs/promises`, per `docs/testing.md`. - Base reproduction (executed): with the production change stashed on base `01788bac8`, `npm run test:focused -- tests/process-global/modelHostReadFailure.test.ts`: 2 failed, both `expected { code: 'target_unavailable', … } to match object { code: 'execution_failure', … }` for the `EMFILE` open fault. - Mutation checks (executed, `npm run test:focused` on the new and boundary model tests): removing the code filter, removing each of the seven codes individually, and emptying the set each made the run fail with assertion errors (9 of 9 mutants caught). - User-visible CLI output (executed, built CLI `node scripts/rea.mjs inspect-model-artifact <path> --json` on macOS): a missing file, a directory, a path under a regular file, a symlink and a FIFO all still return `target_unavailable` / `unavailable`. - Remaining proof gaps: host faults are injected through a mocked `node:fs/promises`; real descriptor exhaustion and device failures were not produced. Windows was not run (there a locked file's `EBUSY` would now be `execution_failure`). If a socket path disappears between the failed open and `nonRegularOpenFailure`'s follow-up `lstat`, the raw `ENXIO`/`EOPNOTSUPP` now reports `execution_failure` instead of `target_unavailable`; this is a narrow race and was left as is. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed Run on macOS 27 arm64, Node from `.nvmrc`, base `01788bac8`. After a rebase onto green main `166fb0820`, the focused tests, `check:fast`, `test:changed` and `docs:check` were run again and passed. - `npm run test:focused -- tests/process-global/modelHostReadFailure.test.ts tests/boundary/model/modelArtifact.test.ts tests/acceptance/modelArtifactCli.test.ts`: 3 files, 76 tests passed. - Same new test with the production change stashed: 2 failed (base reproduction above). - Mutation run over the new and boundary model tests: 9 of 9 mutants failed with assertion errors. - `npm run check:fast`: 2 of 2 tasks successful. - `npm run test:changed -- --base 01788bac8`: 2 files, 3 tests passed. Rerun after the rebase with `--base 166fb0820`: 3 files, 4 tests passed. - `npm run verify:test-discovery`: discovered all 1930 test files exactly once. - `npm run check`: exit 0, module boundaries checked in 2483 source files, architecture guards passed across 1727 source files. - `node scripts/rea.mjs inspect-model-artifact <path> --json` after `npm run build:cached`: missing file, directory, path under a regular file, symlink and FIFO each returned `target_unavailable` / `unavailable`. - Independent adversarial review (read-only, own worktree): no blocking findings. It traced every coded error that can reach the branch, confirmed on macOS that symlink, symlink loop, directory, FIFO, Unix socket, missing file, `ENOTDIR`, a 300-character name and `/dev/null` still produce `BinaryTargetError`, and confirmed no test, doc or contract expects `target_unavailable` for non-path host errors. It reported the socket race listed under proof gaps. - `npm run docs:check`: exit 0. - Automated code review (high effort) on the working-tree diff, each finding checked by hand: - The open-stage handle assertion was vacuous when no handle was opened. Fixed: the read stage now also asserts a handle was captured. - The public error split was undocumented. Fixed: one sentence in `docs/model-artifacts.md`. - It claimed the new `execution_failure` is retryable. Not so: the test now pins `retryable: false`, matching the issue's uncoded control. - `src/gpu/GpuCodeObjectsProvider.ts:181` has the same catch-all coded-error branch. Confirmed, but outside this issue; left for a separate issue. - Suggestions not taken: remapping `ESTALE` (`RegularFileChangedError`) to the artifact-changed error and rewording `ELOOP` (both unchanged from base), a typed resource error for `EMFILE`/`ENFILE`, and moving classification into the shared `BinaryTargetResolver` classifier (which would change other callers). Each is a separate behavior change. - After these changes the base run, mutation run, focused tests, `check:fast`, `test:changed`, `docs:check` and `npm run check` were all rerun with the results above. ## Compatibility, safety, and release - Breaking changes or migration steps: none. Callers that branched on `target_unavailable` for non-path host errors from model inspection now see `execution_failure`, which is the outcome the issue asks for. - Real Hopper/Ghidra, browser, or OS coverage: not applicable. The model provider parses local files directly; the real provider was exercised through the built CLI on macOS 27 arm64. - Package or release metadata impact: none. - Security, privacy, process, or containment review: no new reads, paths or processes. Reported reasons are the same host messages that were already returned. ## Author readiness Human owner: @amyanger - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-11-01 21:45:58 +00:00
bsakaguchi changed title from [PR #6175] [MERGED] fix(model): keep host I/O failures distinct from unavailable model targets to [PR #6175] fix(model): keep host I/O failures distinct from unavailable model targets 2026-11-04 16:32:38 +00:00
bsakaguchi changed title from [PR #6175] fix(model): keep host I/O failures distinct from unavailable model targets to [PR #6175] [MERGED] fix(model): keep host I/O failures distinct from unavailable model targets 2026-11-04 17:28:42 +00:00
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#7184
No description provided.