[GH-ISSUE #4866] [Bug] Artifact cleanup metadata can report recovery without cleanup capability #3022

New issue

Closed

opened 2026-10-31 00:35:01 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:35:01 +00:00

Owner

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

Before submitting

Searched related cleanup reports; #2541/#2542 cover diagnostics and member ownership, #4865 covers physical primary projection.
No credentials or private target data included.

Area

Evidence, artifacts, or reconstruction

Observed behavior

On main8a247fc70, ArtifactAnalysisResources.cleanupFailure accepts cleanup metadata without an exact cleanup capability. With an empty artifact scope, closing the resources clears cleanupIncomplete even though no owner released the reported resource; its historical resource label remains.

Reproduction

A no-OS-resource control supplies an ArtifactReaderFailure with cleanup metadata for unverified-resource, but no retained owner or lease. Call the shared cleanup helper, then close the empty resource scope. The error changes from incomplete to resolved without a cleanup attempt for that resource. This is an authored production-boundary control, not an observed leaked operating-system resource. The local artifact-resource-followup probe records this independently of the real-descriptor primary failure in #4865.

Expected behavior

Unknown cleanup capability must remain unresolved and block replacement admission. Scope-owned cleanup failures should expose their exact canonical leases for successful recovery. An empty scope cannot establish recovery of an unreported owner.

Impact and scope

Observed shared resource/error boundary with authored metadata. NOT_ENOUGH_INFO: public CLI/MCP incident, affected real-provider frequency, naturally occurring resource leak.

REA version

6.5.0, 8a247fc70f

Runtime and platform

Node24.18.0, macOS arm64.

Target and artifact context

No target, producer, or OS resource in this control.

Interface

Other: shared artifact resource ownership.

Earliest failure stage

Cleanup, cancellation, or lifecycle

Relevant output or evidence

Before close: cleanupIncomplete=true. After closing empty scope: cleanupIncomplete=false; cleanupResources retains unverified-resource. No exact cleanup capability was supplied or invoked.

Typed outcome or recovery expected

Keep unresolved ownership truthful; resolve only exact cleanup dependencies.

Analysis or suspected cause

The helper ties recovery to its scope-wide retry wrapper rather than exact source capabilities. ArtifactResourceRetryFailure also infers leases only for selected owner variants, leaving ordinary scope owners without a canonical recovery link.

Originally created by @morluto on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4866 ### Before submitting - [x] Searched related cleanup reports; #2541/#2542 cover diagnostics and member ownership, #4865 covers physical primary projection. - [x] No credentials or private target data included. ### Area Evidence, artifacts, or reconstruction ### Observed behavior On main8a247fc70, ArtifactAnalysisResources.cleanupFailure accepts cleanup metadata without an exact cleanup capability. With an empty artifact scope, closing the resources clears cleanupIncomplete even though no owner released the reported resource; its historical resource label remains. ### Reproduction A no-OS-resource control supplies an ArtifactReaderFailure with cleanup metadata for `unverified-resource`, but no retained owner or lease. Call the shared cleanup helper, then close the empty resource scope. The error changes from incomplete to resolved without a cleanup attempt for that resource. This is an authored production-boundary control, not an observed leaked operating-system resource. The local artifact-resource-followup probe records this independently of the real-descriptor primary failure in #4865. ### Expected behavior Unknown cleanup capability must remain unresolved and block replacement admission. Scope-owned cleanup failures should expose their exact canonical leases for successful recovery. An empty scope cannot establish recovery of an unreported owner. ### Impact and scope Observed shared resource/error boundary with authored metadata. NOT_ENOUGH_INFO: public CLI/MCP incident, affected real-provider frequency, naturally occurring resource leak. ### REA version 6.5.0, 8a247fc70f8294d4e8cfe920007eb135a965bb77 ### Runtime and platform Node24.18.0, macOS arm64. ### Target and artifact context No target, producer, or OS resource in this control. ### Interface Other: shared artifact resource ownership. ### Earliest failure stage Cleanup, cancellation, or lifecycle ### Relevant output or evidence Before close: cleanupIncomplete=true. After closing empty scope: cleanupIncomplete=false; cleanupResources retains `unverified-resource`. No exact cleanup capability was supplied or invoked. ### Typed outcome or recovery expected Keep unresolved ownership truthful; resolve only exact cleanup dependencies. ### Analysis or suspected cause The helper ties recovery to its scope-wide retry wrapper rather than exact source capabilities. ArtifactResourceRetryFailure also infers leases only for selected owner variants, leaving ordinary scope owners without a canonical recovery link.

bsakaguchi closed this issue

2026-10-31 00:35:01 +00:00

bsakaguchi referenced this issue

2026-10-31 01:07:38 +00:00

[PR #3028] feat(cli): run ordered tool batches in one provider session #5567

bsakaguchi referenced this issue

2026-10-31 01:07:38 +00:00

[PR #3029] fix(ghidra): recover registered Borland SEH handler gaps #5568