[GH-ISSUE #2592] fix(session): unknown environment provider is accepted as unbound #909

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Summary

An unknown provider identifier configured through REA_ANALYSIS_PROVIDER can pass selection as an intentionally unbound target when every registered deep provider rejects the target. Later deep-operation diagnostics blame target support instead of the unknown configuration. Passing the same identifier explicitly correctly rejects it.

Steps to reproduce

On the source baseline below, configure REA_ANALYSIS_PROVIDER=missing-provider and register one candidate with a different valid identifier. Give that candidate available status, one declared deep operation, and unsupported target status for an archive target.
Call AnalysisProviderRegistry.select(target) using the configured selector and inspect the result and binding. For a successful selection, obtain its unboundOperationError for the declared operation.
Call select(target, "missing-provider") on the same candidate registry as an explicit-request control.
Repeat the default selection with the registered candidate's identifier as a second control.

Expected behavior

An unknown concrete provider identifier must retain the unknown_provider selection failure. Intentional unbound success remains valid for a registered environment preference when no deep provider supports the target.

Actual behavior

The focused test observed success and a null binding for the unknown configured identifier, followed by target_unsupported from the unbound deep-operation error. The explicit request returned unknown_provider. The registered-default control remained successfully unbound. Configuration parsing also accepted the syntactically valid unknown identifier.

Evidence

Expected source: AGENTS.md requires unresolved identity to remain unknown; src/application/binary/AnalysisProviderRegistry.ts:230 returns unknown_provider when a concrete identifier is absent from the registry.
Failure source: src/application/binary/AnalysisProviderRegistry.ts:171 returns unbound success for unsupported targets before the concrete identity check, and line 208 assigns the later target-support error. src/contracts/providerSelection.ts:16 admits valid concrete IDs at the configuration boundary.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

Two focused tests passed and directly checked configuration parsing, both selection paths, the downstream error, and the registered-default control. Full CLI/MCP open was not executed; production routing forwards the successful registry selection.

Runtime or environment

Source revision 8b181716ac, Node.js v26.10.0, npm 11.19.1, installed locked dependencies, and Vitest 5.0.3.

Restoration check

The unknown configured selector and explicit unknown selector must both fail with unknown_provider. Keep the registered-default unsupported-target control successfully unbound so artifact-only routing remains available.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: A malformed provider choice appears successful and later diagnostics incorrectly blame target support, which obscures the configuration error. The failure is bounded to unknown default identifiers and targets rejected by every candidate.
Workaround status: available
Workaround basis: The focused test confirmed that supplying the unknown identifier explicitly produces the correct diagnostic. Correcting the default to a registered identifier removes the unknown-identity condition while preserving intentional artifact-only routing.

Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2592 ## Summary An unknown provider identifier configured through `REA_ANALYSIS_PROVIDER` can pass selection as an intentionally unbound target when every registered deep provider rejects the target. Later deep-operation diagnostics blame target support instead of the unknown configuration. Passing the same identifier explicitly correctly rejects it. ## Steps to reproduce 1. On the source baseline below, configure `REA_ANALYSIS_PROVIDER=missing-provider` and register one candidate with a different valid identifier. Give that candidate available status, one declared deep operation, and unsupported target status for an archive target. 2. Call `AnalysisProviderRegistry.select(target)` using the configured selector and inspect the result and binding. For a successful selection, obtain its `unboundOperationError` for the declared operation. 3. Call `select(target, "missing-provider")` on the same candidate registry as an explicit-request control. 4. Repeat the default selection with the registered candidate's identifier as a second control. ## Expected behavior An unknown concrete provider identifier must retain the `unknown_provider` selection failure. Intentional unbound success remains valid for a registered environment preference when no deep provider supports the target. ## Actual behavior The focused test observed success and a null binding for the unknown configured identifier, followed by `target_unsupported` from the unbound deep-operation error. The explicit request returned `unknown_provider`. The registered-default control remained successfully unbound. Configuration parsing also accepted the syntactically valid unknown identifier. ## Evidence - Expected source: `AGENTS.md` requires unresolved identity to remain unknown; `src/application/binary/AnalysisProviderRegistry.ts:230` returns `unknown_provider` when a concrete identifier is absent from the registry. - Failure source: `src/application/binary/AnalysisProviderRegistry.ts:171` returns unbound success for unsupported targets before the concrete identity check, and line 208 assigns the later target-support error. `src/contracts/providerSelection.ts:16` admits valid concrete IDs at the configuration boundary. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete Two focused tests passed and directly checked configuration parsing, both selection paths, the downstream error, and the registered-default control. Full CLI/MCP open was not executed; production routing forwards the successful registry selection. ## Runtime or environment Source revision 8b181716aca2cb467be499cba226abfb5ae19141, Node.js v26.10.0, npm 11.19.1, installed locked dependencies, and Vitest 5.0.3. ## Restoration check The unknown configured selector and explicit unknown selector must both fail with `unknown_provider`. Keep the registered-default unsupported-target control successfully unbound so artifact-only routing remains available. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: A malformed provider choice appears successful and later diagnostics incorrectly blame target support, which obscures the configuration error. The failure is bounded to unknown default identifiers and targets rejected by every candidate. - Workaround status: available - Workaround basis: The focused test confirmed that supplying the unknown identifier explicitly produces the correct diagnostic. Correcting the default to a registered identifier removes the unknown-identity condition while preserving intentional artifact-only routing.

bsakaguchi

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

closed this issue
added the
bug
label

bsakaguchi referenced this issue

2026-10-16 21:17:29 +00:00

[PR #909] [MERGED] perf(call-path): prune dead ends and enumerate without recursion #2338

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#909

No description provided.

Rows
Columns