[GH-ISSUE #2621] fix(managed): avoid a false duplicate-ID diagnostic for one native observation #937

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Summary

The input validator for managed/native verification reports a duplicate-native-ID error when the request contains only one native observation whose ID equals the managed-boundary ID. The correct distinctness error is also present, and the request is rejected. A focused probe reproduced the extra message in both the request schema and the input validator passed to tool registration; the domain schema reports only the correct distinctness failure.

Steps to reproduce

Use the source checkout and locked dependencies under Runtime or environment. Add the following test as src/contracts/managed/nativeVerificationDiagnostics.test.ts and run npm run test:focused -- src/contracts/managed/nativeVerificationDiagnostics.test.ts. It uses the repository's existing Evidence example and requires no native provider.

import { expect, it } from "vitest";
import { managedNativeVerificationReferenceInputSchema } from "./managedWorkflowToolContracts.js";
import { managedNativeVerificationInputSchema } from "../../domain/managed/managedNativeVerificationSchemas.js";
import { MANAGED_NATIVE_VERIFICATION_EXAMPLE } from "./managedWorkflowExamples.js";

it("reports only role distinctness for a single reused boundary", () => {
  const boundary = MANAGED_NATIVE_VERIFICATION_EXAMPLE.managed_boundaries;
  const input = { managed_boundaries: boundary, native_observations: [boundary] };
  const request = managedNativeVerificationReferenceInputSchema.safeParse(input);
  const domain = managedNativeVerificationInputSchema.safeParse(input);
  expect(request.success).toBe(false);
  expect(domain.success).toBe(false);
  if (request.success || domain.success) throw new Error("Invalid input was accepted");
  expect(request.error.issues.map(issue => issue.message)).toEqual(
    domain.error.issues.map(issue => issue.message),
  );
});

An equivalent focused verification probe executed both parsers and also checked the Standard Schema validator returned by toolRegistrationOptions for verify_managed_native_boundaries. The equality assertion above expresses the restored behavior; the observed request and domain lists differ.

Expected behavior

A single native observation that equals the managed boundary should fail the requirement that the two roles use distinct Evidence. It should not be diagnosed as repeating another native observation, because the native list contains only one entry. Requests with genuinely repeated native IDs must still be rejected for non-uniqueness.

Actual behavior

The request parser returned both "Native observation Evidence must be distinct from managed boundary Evidence" and "Native observation Evidence IDs must be unique". The domain parser returned only the first message. The registered input validator also produced two issues. Both parsers accepted a distinct native observation and reported one uniqueness issue for two repeated native observations distinct from the boundary. Full CLI and MCP transport responses were not exercised.

Evidence

Expected source: src/domain/managed/managedNativeVerificationSchemas.ts:92-117 separates boundary-role distinctness from uniqueness within the native-observation list and reports only distinctness for this fixture.
Failure source: src/contracts/managed/managedWorkflowToolContracts.ts:46-62 seeds the uniqueness set with the boundary ID and emits both messages. The focused probe directly observed that result and its preservation in the registration validator produced by src/server/toolRegistrationOptions.ts:31.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

The focused verification test passed in 1.23 seconds and printed both diagnostic lists. The production registration supplies this input schema before the handler resolves Evidence roles; later role checks do not remove its initial diagnostic. The probe checked only validation and controls, without running native analysis or publishing Evidence.

Restoration check

For the same single reused-boundary fixture, require rejection with exactly the distinctness issue at native_observations[0] and agreement with the domain validator. A distinct native observation should still pass input validation. Two native observations with the same ID, distinct from the boundary, should still produce exactly one uniqueness issue. Preserve rejection of all invalid requests.

Runtime or environment

Source baseline 8b181716ac. The focused probe used Node.js v26.10.0, npm 11.19.1, and installed lockfile dependencies.

Triage assessment

Impact level: P3
Assessment status: supported
Impact basis: An already-invalid request receives one false additional diagnostic while the correct reason remains present. The observation changes diagnostic wording, not request acceptance or native-verification results.
Workaround status: available
Workaround basis: The valid distinctness message already identifies the correction: supply native Evidence distinct from the boundary. The focused controls confirm that a distinct native observation passes input validation.

Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2621 ## Summary The input validator for managed/native verification reports a duplicate-native-ID error when the request contains only one native observation whose ID equals the managed-boundary ID. The correct distinctness error is also present, and the request is rejected. A focused probe reproduced the extra message in both the request schema and the input validator passed to tool registration; the domain schema reports only the correct distinctness failure. ## Steps to reproduce Use the source checkout and locked dependencies under Runtime or environment. Add the following test as src/contracts/managed/nativeVerificationDiagnostics.test.ts and run `npm run test:focused -- src/contracts/managed/nativeVerificationDiagnostics.test.ts`. It uses the repository's existing Evidence example and requires no native provider. ```ts import { expect, it } from "vitest"; import { managedNativeVerificationReferenceInputSchema } from "./managedWorkflowToolContracts.js"; import { managedNativeVerificationInputSchema } from "../../domain/managed/managedNativeVerificationSchemas.js"; import { MANAGED_NATIVE_VERIFICATION_EXAMPLE } from "./managedWorkflowExamples.js"; it("reports only role distinctness for a single reused boundary", () => { const boundary = MANAGED_NATIVE_VERIFICATION_EXAMPLE.managed_boundaries; const input = { managed_boundaries: boundary, native_observations: [boundary] }; const request = managedNativeVerificationReferenceInputSchema.safeParse(input); const domain = managedNativeVerificationInputSchema.safeParse(input); expect(request.success).toBe(false); expect(domain.success).toBe(false); if (request.success || domain.success) throw new Error("Invalid input was accepted"); expect(request.error.issues.map(issue => issue.message)).toEqual( domain.error.issues.map(issue => issue.message), ); }); ``` An equivalent focused verification probe executed both parsers and also checked the Standard Schema validator returned by toolRegistrationOptions for verify_managed_native_boundaries. The equality assertion above expresses the restored behavior; the observed request and domain lists differ. ## Expected behavior A single native observation that equals the managed boundary should fail the requirement that the two roles use distinct Evidence. It should not be diagnosed as repeating another native observation, because the native list contains only one entry. Requests with genuinely repeated native IDs must still be rejected for non-uniqueness. ## Actual behavior The request parser returned both "Native observation Evidence must be distinct from managed boundary Evidence" and "Native observation Evidence IDs must be unique". The domain parser returned only the first message. The registered input validator also produced two issues. Both parsers accepted a distinct native observation and reported one uniqueness issue for two repeated native observations distinct from the boundary. Full CLI and MCP transport responses were not exercised. ## Evidence - Expected source: src/domain/managed/managedNativeVerificationSchemas.ts:92-117 separates boundary-role distinctness from uniqueness within the native-observation list and reports only distinctness for this fixture. - Failure source: src/contracts/managed/managedWorkflowToolContracts.ts:46-62 seeds the uniqueness set with the boundary ID and emits both messages. The focused probe directly observed that result and its preservation in the registration validator produced by src/server/toolRegistrationOptions.ts:31. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete The focused verification test passed in 1.23 seconds and printed both diagnostic lists. The production registration supplies this input schema before the handler resolves Evidence roles; later role checks do not remove its initial diagnostic. The probe checked only validation and controls, without running native analysis or publishing Evidence. ## Restoration check For the same single reused-boundary fixture, require rejection with exactly the distinctness issue at native_observations[0] and agreement with the domain validator. A distinct native observation should still pass input validation. Two native observations with the same ID, distinct from the boundary, should still produce exactly one uniqueness issue. Preserve rejection of all invalid requests. ## Runtime or environment Source baseline 8b181716aca2cb467be499cba226abfb5ae19141. The focused probe used Node.js v26.10.0, npm 11.19.1, and installed lockfile dependencies. ## Triage assessment - Impact level: P3 - Assessment status: supported - Impact basis: An already-invalid request receives one false additional diagnostic while the correct reason remains present. The observation changes diagnostic wording, not request acceptance or native-verification results. - Workaround status: available - Workaround basis: The valid distinctness message already identifies the correction: supply native Evidence distinct from the boundary. The focused controls confirm that a distinct native observation passes input validation.

bsakaguchi

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