morluto/rea

Fork 0

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

[GH-ISSUE #4240] [Bug] Direct CLI cleanup composition drops primary cleanup resource diagnostics #1665

New issue

Closed

opened 2026-10-16 21:08:44 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-16 21:08:44 +00:00

Owner

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

Observed behavior

When direct analysis already returns a cleanup error and the subsequent session close returns a second cleanup error, the final CLI projection drops the original error's resource names entirely.

Executed on PR #4238 head 6e64a09a3 (REA 6.5.0, Node 24.18.0, macOS 26.3 arm64), using the production runDirectAnalysis, BinarySession, provider routing and error projection with a controlled provider port. No real engine or resource leak was simulated or claimed. The resource names are diagnostic fixture values.

Primary analysis error	Session close	Final output
`cleanup_incomplete`, resources `["primary-snapshot"]`	succeeds	`primary-snapshot` remains in the output
Same primary error	fails with resources `["close-runtime"]`	Final resources are only `["close-runtime"]`; `primary-snapshot` is absent from the entire serialized output

Related: #4227, #3935. This is a separate application-layer projection case from the provider CLI close/finally result loss addressed in #4238. Closed #1501 concerned firmware provider retention, not this resource-field overwrite.

Small reproduction at the owning boundary

After building, run from the repository root:

import { directAnalysisCleanupFailure } from './dist/application/DirectAnalysisCleanup.js';
import { projectAnalysisError } from './dist/domain/analysisErrorProjection.js';
import { ProviderCleanupError } from './dist/domain/providerCleanupError.js';

const primary = new ProviderCleanupError('fixture', ['primary-snapshot'], {reason: 'first cleanup failed'});
const closing = new ProviderCleanupError('fixture', ['close-runtime'], {reason: 'second cleanup failed'});
const output = directAnalysisCleanupFailure(
  {error: 'Analysis failed', ...projectAnalysisError(primary)}, closing,
);
console.log(output.details.resources);
console.log(JSON.stringify(output).includes('primary-snapshot'));

This reproduces the same owning projection used by the executed full application workflow: resources are ["close-runtime"], and the final check is false. The application control with successful session close preserves the original resource.

Root cause

src/application/DirectAnalysisCleanup.ts, directAnalysisCleanupFailure, spreads the primary projection's details and then overwrites resources with error.cleanupResources. It retains the secondary error as cleanup_error, but keeps no separate primary projection containing the overwritten fields. The same overwrite exists in main e2db76801; the runtime probe was executed on the PR head.

Expected behavior and regression

Preserve the original primary cleanup diagnostic, including its reported resources, alongside the later close diagnostic. Keep historical diagnostics distinct from any current remaining-resource assessment: a later close error alone does not prove what happened to a resource named by the primary error.

Cover primary-cleanup-error plus successful close and primary-cleanup-error plus another cleanup failure through the direct application/CLI workflow. Keep captured output and partial observations without duplicating large payloads. No repair is included or claimed in this report.

Originally created by @morluto on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4240 ### Observed behavior When direct analysis already returns a cleanup error and the subsequent session close returns a second cleanup error, the final CLI projection drops the original error's resource names entirely. Executed on PR #4238 head `6e64a09a3` (REA 6.5.0, Node 24.18.0, macOS 26.3 arm64), using the production `runDirectAnalysis`, BinarySession, provider routing and error projection with a controlled provider port. No real engine or resource leak was simulated or claimed. The resource names are diagnostic fixture values. | Primary analysis error | Session close | Final output | | --- | --- | --- | | `cleanup_incomplete`, resources `["primary-snapshot"]` | succeeds | `primary-snapshot` remains in the output | | Same primary error | fails with resources `["close-runtime"]` | Final resources are only `["close-runtime"]`; `primary-snapshot` is absent from the entire serialized output | Related: #4227, #3935. This is a separate application-layer projection case from the provider CLI close/finally result loss addressed in #4238. Closed #1501 concerned firmware provider retention, not this resource-field overwrite. ### Small reproduction at the owning boundary After building, run from the repository root: ```js import { directAnalysisCleanupFailure } from './dist/application/DirectAnalysisCleanup.js'; import { projectAnalysisError } from './dist/domain/analysisErrorProjection.js'; import { ProviderCleanupError } from './dist/domain/providerCleanupError.js'; const primary = new ProviderCleanupError('fixture', ['primary-snapshot'], {reason: 'first cleanup failed'}); const closing = new ProviderCleanupError('fixture', ['close-runtime'], {reason: 'second cleanup failed'}); const output = directAnalysisCleanupFailure( {error: 'Analysis failed', ...projectAnalysisError(primary)}, closing, ); console.log(output.details.resources); console.log(JSON.stringify(output).includes('primary-snapshot')); ``` This reproduces the same owning projection used by the executed full application workflow: resources are `["close-runtime"]`, and the final check is false. The application control with successful session close preserves the original resource. ### Root cause `src/application/DirectAnalysisCleanup.ts`, `directAnalysisCleanupFailure`, spreads the primary projection's details and then overwrites `resources` with `error.cleanupResources`. It retains the secondary error as `cleanup_error`, but keeps no separate primary projection containing the overwritten fields. The same overwrite exists in main `e2db76801`; the runtime probe was executed on the PR head. ### Expected behavior and regression Preserve the original primary cleanup diagnostic, including its reported resources, alongside the later close diagnostic. Keep historical diagnostics distinct from any current remaining-resource assessment: a later close error alone does not prove what happened to a resource named by the primary error. Cover primary-cleanup-error plus successful close and primary-cleanup-error plus another cleanup failure through the direct application/CLI workflow. Keep captured output and partial observations without duplicating large payloads. No repair is included or claimed in this report.

bsakaguchi commented

2026-10-16 21:08:46 +00:00

Author

Owner

@morluto commented on GitHub (Oct 15, 2026):

Fixed on PR #4238 in 3bd6c99ce.

The direct CLI composition now preserves the original error details, including its resource names and cleanup reason. The later close assessment remains in details.cleanup_error with its own resources and recovery action. These remain separate diagnostics; no inferred union or claim of current liveness is added. Captured output stays inline without duplication. The CLI docs explain the two assessments.

The production runDirectAnalysis regression fails before repair when final close fails, while its successful-close control passes. Both now pass, along with the seven-file focused suite (89 tests), full static checks, docs checks and pre-push checks. This verifies controlled application/provider boundaries; it does not demonstrate a physical resource leak or new real-engine behavior. The PR links this issue for closure on merge.

@morluto commented on GitHub (Oct 15, 2026): Fixed on PR #4238 in 3bd6c99ce. The direct CLI composition now preserves the original error details, including its resource names and cleanup reason. The later close assessment remains in `details.cleanup_error` with its own resources and recovery action. These remain separate diagnostics; no inferred union or claim of current liveness is added. Captured output stays inline without duplication. The CLI docs explain the two assessments. The production `runDirectAnalysis` regression fails before repair when final close fails, while its successful-close control passes. Both now pass, along with the seven-file focused suite (89 tests), full static checks, docs checks and pre-push checks. This verifies controlled application/provider boundaries; it does not demonstrate a physical resource leak or new real-engine behavior. The PR links this issue for closure on merge.

bsakaguchi commented

2026-10-16 21:08:46 +00:00

Author

Owner

@official-rex commented on GitHub (Oct 15, 2026):

I can investigate and fix the cleanup error projection while preserving the original resource names. Kindly assign me this issue; I look forward to your response.

@official-rex commented on GitHub (Oct 15, 2026): I can investigate and fix the cleanup error projection while preserving the original resource names. Kindly assign me this issue; I look forward to your response.

bsakaguchi closed this issue

2026-10-31 00:32:06 +00:00

bsakaguchi commented

2026-10-31 00:32:06 +00:00

Author

Owner

@morluto commented on GitHub (Oct 18, 2026):

Reconciled against current main (279c590ef). The producing correction is already present in 0e1f0bf2d (PR #4238): primary details retain their resources, and the later close assessment remains under cleanup_error.

Fresh validation: all 10 tests in tests/composition/directAnalysisCleanup.test.ts passed through direct application/session composition, including original cleanup diagnostics with successful and failed final close. Also executed the report's exact compiled owner-boundary control with primary-snapshot + close-runtime: top-level resources retain primary-snapshot; cleanup_error.details.resources retains close-runtime. No production code change was needed for this report.

This is controlled application/error-boundary verification on macOS arm64, not a native-engine leak or platform cleanup qualification. Closing as addressed; broader lifecycle work remains #4227.

@morluto commented on GitHub (Oct 18, 2026): Reconciled against current main (279c590ef). The producing correction is already present in 0e1f0bf2d (PR #4238): primary details retain their resources, and the later close assessment remains under cleanup_error. Fresh validation: all 10 tests in tests/composition/directAnalysisCleanup.test.ts passed through direct application/session composition, including original cleanup diagnostics with successful and failed final close. Also executed the report's exact compiled owner-boundary control with primary-snapshot + close-runtime: top-level resources retain primary-snapshot; cleanup_error.details.resources retains close-runtime. No production code change was needed for this report. This is controlled application/error-boundary verification on macOS arm64, not a native-engine leak or platform cleanup qualification. Closing as addressed; broader lifecycle work remains #4227.

bsakaguchi referenced this issue

2026-10-31 00:49:41 +00:00

[GH-ISSUE #7418] [Bug] analyze-javascript-application retains a stale literal after a member assignment inside with #4424

bsakaguchi referenced this issue

2026-10-31 00:55:14 +00:00

[PR #1767] [MERGED] fix(javascript): bound self-alias mutation paths that never prune #4805