[GH-ISSUE #6525] [Bug] Environment sorted insertion ignores retained submillisecond timestamp precision #3916

New issue

Closed

opened 2026-10-31 00:45:13 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:45:13 +00:00

Owner

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

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

Source-only finding: environment state sorting treats distinct ISO timestamps within one millisecond as equal. readClock explicitly preserves fractional digits beyond milliseconds in subMillisecond, but the sorting owner compareValues subtracts only ms and ignores that retained remainder.

This makes a strictly timestamp-ordered collection fail sorted-insertion inference. When a sorted insert rule is already selected, it can put a new earlier timestamp after later timestamps in the same millisecond. No runtime reproduction of this finding was performed.

Reproduction

Proposed, not run:

Call compareValues with 2000-01-01T12:00:00.123000001Z and 2000-01-01T12:00:00.123000002Z. Source-derived result: zero; expected: negative.
Call insertCandidates with two objects whose at values are the timestamps above and fields: ["at"]. Source-derived result omits the ascending sorted rule because the order is zero.
Call insertIndex with { rule: "sorted", field: "at", direction: "ascending" }, existing objects at .123000002Z and .123000003Z, and a new object at .123000001Z. Source-derived result: index 2 rather than index 0.

NOT_ENOUGH_INFO: no executed result or occurrence frequency is available. These are proposed checks of the real sorting owner, not claims of an end-to-end environment reproduction.

Expected behavior

Compare the complete retained instant: use the millisecond ordering first and the submillisecond remainder when milliseconds tie. Timestamp-sorted inference and replay insertion should preserve the order of supported fractional timestamps.

The clock representation explicitly retains nanoseconds so distinct recorded instants remain distinct. The sorting owner's own contract is to order values as instants; this report does not ask for finer precision than the parser already preserves.

Impact and scope

The source-derived affected class is ISO timestamp fields with 4–9 fractional digits whose values differ only below millisecond precision. The result can be missing sorted-rule inference or incorrect insertion position in a timestamp-sorted replay collection. Whole-millisecond differences still use the retained millisecond value. Real-world prevalence and full environment outputs were not measured.

NOT_ENOUGH_INFO: no practical workaround preserving the recorded timestamps and required ordering was tested.

REA version

Main source revision 49c9c9d4a14cc7d5509ec28a304dab48f85cb045 (package metadata says 6.7.0). The clock implementation is absent from latest published tag rea-agents-6.7.0, commit 27dc42d10249f0410904a75c0997842eb03b931c; no published-package affectedness is claimed.

Runtime and platform

Source review on Linux x64. NOT_ENOUGH_INFO: no runtime, platform compatibility, or provider reproduction was performed for this finding.

Target and artifact context

Environment state collections ordered by a recorded ISO timestamp field with submillisecond precision. Inputs above are synthetic.

Interface

Other

Shared environment state inference and insertion logic; CLI and MCP were not executed.

Earliest failure stage

Transport or result projection

Relevant output or evidence

Source-derived evidence only:

Clock parsing retains the submillisecond remainder.

Instant comparison drops the remainder:

const [c, d] = [readClock(left), readClock(right)];
if (c !== undefined && d !== undefined) return c.ms - d.ms;

Sorted-rule inference requires strict ordering, so a zero result removes a supported sorted candidate.
Replay insertion uses the same incomplete comparator and falls back to the end when no strict comparison matches.
Clock respelling elsewhere compares both parts, confirming the extra precision is meaningful retained identity, rather than unused display metadata.

No runtime output is available. No post-draft reverification was performed.

Triage assessment

Impact level: P2
Assessment status: provisional
Impact basis: The shared ordering source collapses supported distinct instants, suppressing sorted-rule inference and producing incorrect sorted insertion positions; no integrated runtime result or user incident was observed.
Workaround status: unverified
Workaround basis: Reducing timestamp precision would discard required ordering information, and no alternative user-level restoration was demonstrated.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6525 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior Source-only finding: environment state sorting treats distinct ISO timestamps within one millisecond as equal. `readClock` explicitly preserves fractional digits beyond milliseconds in `subMillisecond`, but the sorting owner `compareValues` subtracts only `ms` and ignores that retained remainder. This makes a strictly timestamp-ordered collection fail sorted-insertion inference. When a sorted insert rule is already selected, it can put a new earlier timestamp after later timestamps in the same millisecond. No runtime reproduction of this finding was performed. ### Reproduction Proposed, not run: 1. Call `compareValues` with `2000-01-01T12:00:00.123000001Z` and `2000-01-01T12:00:00.123000002Z`. Source-derived result: zero; expected: negative. 2. Call `insertCandidates` with two objects whose `at` values are the timestamps above and `fields: ["at"]`. Source-derived result omits the ascending sorted rule because the order is zero. 3. Call `insertIndex` with `{ rule: "sorted", field: "at", direction: "ascending" }`, existing objects at `.123000002Z` and `.123000003Z`, and a new object at `.123000001Z`. Source-derived result: index 2 rather than index 0. `NOT_ENOUGH_INFO`: no executed result or occurrence frequency is available. These are proposed checks of the real sorting owner, not claims of an end-to-end environment reproduction. ### Expected behavior Compare the complete retained instant: use the millisecond ordering first and the submillisecond remainder when milliseconds tie. Timestamp-sorted inference and replay insertion should preserve the order of supported fractional timestamps. The [clock representation](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/analysisView/environmentStateWriteValues.ts#L13-L18) explicitly retains nanoseconds so distinct recorded instants remain distinct. The sorting owner's own contract is to order values as instants; this report does not ask for finer precision than the parser already preserves. ### Impact and scope The source-derived affected class is ISO timestamp fields with 4–9 fractional digits whose values differ only below millisecond precision. The result can be missing sorted-rule inference or incorrect insertion position in a timestamp-sorted replay collection. Whole-millisecond differences still use the retained millisecond value. Real-world prevalence and full environment outputs were not measured. `NOT_ENOUGH_INFO`: no practical workaround preserving the recorded timestamps and required ordering was tested. ### REA version Main source revision `49c9c9d4a14cc7d5509ec28a304dab48f85cb045` (package metadata says 6.7.0). The clock implementation is absent from latest published tag `rea-agents-6.7.0`, commit `27dc42d10249f0410904a75c0997842eb03b931c`; no published-package affectedness is claimed. ### Runtime and platform Source review on Linux x64. `NOT_ENOUGH_INFO`: no runtime, platform compatibility, or provider reproduction was performed for this finding. ### Target and artifact context Environment state collections ordered by a recorded ISO timestamp field with submillisecond precision. Inputs above are synthetic. ### Interface Other Shared environment state inference and insertion logic; CLI and MCP were not executed. ### Earliest failure stage Transport or result projection ### Relevant output or evidence Source-derived evidence only: - [Clock parsing retains the submillisecond remainder](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/analysisView/environmentStateWriteValues.ts#L62-L70). - [Instant comparison drops the remainder](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/analysisView/environmentStateWriteExplain.ts#L426-L437): ```ts const [c, d] = [readClock(left), readClock(right)]; if (c !== undefined && d !== undefined) return c.ms - d.ms; ``` - [Sorted-rule inference requires strict ordering](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/analysisView/environmentStateWriteExplain.ts#L440-L465), so a zero result removes a supported sorted candidate. - [Replay insertion uses the same incomplete comparator](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/analysisView/environmentStateWriteExplain.ts#L468-L482) and falls back to the end when no strict comparison matches. - [Clock respelling elsewhere compares both parts](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/analysisView/environmentStateGate.ts#L138-L150), confirming the extra precision is meaningful retained identity, rather than unused display metadata. No runtime output is available. No post-draft reverification was performed. ## Triage assessment - Impact level: P2 - Assessment status: provisional - Impact basis: The shared ordering source collapses supported distinct instants, suppressing sorted-rule inference and producing incorrect sorted insertion positions; no integrated runtime result or user incident was observed. - Workaround status: unverified - Workaround basis: Reducing timestamp precision would discard required ordering information, and no alternative user-level restoration was demonstrated.

bsakaguchi closed this issue

2026-10-31 00:45:13 +00:00

bsakaguchi referenced this issue

2026-10-31 01:13:30 +00:00

[PR #4572] fix(reference): keep the raw query and fragment on unresolved ESM paths #6314

bsakaguchi referenced this issue

2026-11-01 21:10:53 +00:00

[GH-ISSUE #3582] [Tracker] Ready to close or merge: issues and pull requests (October 2026) #1330