[PR #2739] [MERGED] fix(process): order interaction differences by their dispatch time #5355

New issue

Closed

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

bsakaguchi commented

2026-10-31 01:05:58 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2739
Author: @kaoru0822-kitauji
Created: 10/13/2026
Status: ✅ Merged
Merged: 10/13/2026
Merged by: @kaoru0822-kitauji

Base: main ← Head: fix/issue-2645

📝 Commits (4)

c6aaa1d fix(process): order interaction differences by their dispatch time
bf3db19 fix(process): require ordered interaction dispatch times in captures
e8e3cfd Merge remote-tracking branch 'origin/main' into fix/issue-2645
15a2870 Merge remote-tracking branch 'origin/main' into fix/issue-2645

📊 Changes

4 files changed (+128 additions, -19 deletions)

View changed files

📝 src/domain/process/processCapture.comparison.test.ts (+72 -0)
📝 src/domain/process/processCapture.validation.test.ts (+24 -0)
📝 src/domain/process/processCaptureValidation.ts (+11 -6)
📝 src/domain/process/processComparison.ts (+21 -13)

📄 Description

Fixes #2645.

Problem

compareProcessCaptures picks first_divergence by sorting the per-dimension first differences on the earliest recorded time of the two differing observations (chooseFirstDivergence). That time came from eventTime, which read only an at_ms field. Interaction events don't have at_ms; they record scheduled_at_ms and dispatched_at_ms. So a changed interaction always got left_at_ms/right_at_ms of null and sorted as if it happened at Number.MAX_SAFE_INTEGER.

In the issue's captures, an interaction outcome differs at a 6 ms dispatch and a process sample differs at 500 ms. first_divergence named the process sample at 500 ms, giving callers the wrong starting point for diagnosis.

Fix

eventTime now takes the dimension and reads that dimension's recorded time field:

interaction: dispatched_at_ms, the time the outcome was observed.
terminal, exit, filesystem, process: at_ms, as before.

first_divergence for interactions now reports left_at_ms/right_at_ms (6/6 in the issue's case) and is ranked by that time. As the issue asks, this concerns recorded time only and makes no causal claim.

Validation

New processCapture.comparison.test.ts cases use the issue's fully observed captures:
- A process sample at 500 ms: first_divergence is the interaction at 6/6 ms. This fails on main and passes here.
- The control, a process sample at 4 ms: first_divergence stays the process sample at 4/4 ms. This passes both before and after.
src/domain/process: 6 files, 54 tests pass. Process-capture comparison boundary suites (compare-process-captures / first_divergence): 10 files, 99 tests pass. npm run check:fast and format:check pass.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2739 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/13/2026 **Status:** ✅ Merged **Merged:** 10/13/2026 **Merged by:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Base:** `main` ← **Head:** `fix/issue-2645` --- ### 📝 Commits (4) - [`c6aaa1d`](https://github.com/morluto/rea/commit/c6aaa1dcb7970a0e9689bc20baa614d2487395d2) fix(process): order interaction differences by their dispatch time - [`bf3db19`](https://github.com/morluto/rea/commit/bf3db19cab6e33148346013eb339c2c53346daf4) fix(process): require ordered interaction dispatch times in captures - [`e8e3cfd`](https://github.com/morluto/rea/commit/e8e3cfd48bd847060f6651f0c7be25f26c1bd845) Merge remote-tracking branch 'origin/main' into fix/issue-2645 - [`15a2870`](https://github.com/morluto/rea/commit/15a2870c30f8beaf325592d613548297763379a5) Merge remote-tracking branch 'origin/main' into fix/issue-2645 ### 📊 Changes **4 files changed** (+128 additions, -19 deletions) <details> <summary>View changed files</summary> 📝 `src/domain/process/processCapture.comparison.test.ts` (+72 -0) 📝 `src/domain/process/processCapture.validation.test.ts` (+24 -0) 📝 `src/domain/process/processCaptureValidation.ts` (+11 -6) 📝 `src/domain/process/processComparison.ts` (+21 -13) </details> ### 📄 Description Fixes #2645. ## Problem `compareProcessCaptures` picks `first_divergence` by sorting the per-dimension first differences on the earliest recorded time of the two differing observations (`chooseFirstDivergence`). That time came from `eventTime`, which read only an `at_ms` field. Interaction events don't have `at_ms`; they record `scheduled_at_ms` and `dispatched_at_ms`. So a changed interaction always got `left_at_ms`/`right_at_ms` of `null` and sorted as if it happened at `Number.MAX_SAFE_INTEGER`. In the issue's captures, an interaction outcome differs at a 6 ms dispatch and a process sample differs at 500 ms. `first_divergence` named the process sample at 500 ms, giving callers the wrong starting point for diagnosis. ## Fix `eventTime` now takes the dimension and reads that dimension's recorded time field: - `interaction`: `dispatched_at_ms`, the time the outcome was observed. - `terminal`, `exit`, `filesystem`, `process`: `at_ms`, as before. `first_divergence` for interactions now reports `left_at_ms`/`right_at_ms` (6/6 in the issue's case) and is ranked by that time. As the issue asks, this concerns recorded time only and makes no causal claim. ## Validation - New `processCapture.comparison.test.ts` cases use the issue's fully observed captures: - A process sample at 500 ms: `first_divergence` is the interaction at 6/6 ms. This fails on main and passes here. - The control, a process sample at 4 ms: `first_divergence` stays the process sample at 4/4 ms. This passes both before and after. - `src/domain/process`: 6 files, 54 tests pass. Process-capture comparison boundary suites (`compare-process-captures` / `first_divergence`): 10 files, 99 tests pass. `npm run check:fast` and `format:check` pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:05:58 +00:00