[GH-ISSUE #4873] [Bug] TOML configuration edits rescan every line for each assignment #3026

New issue

Closed

opened 2026-10-31 00:35:04 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:35:04 +00:00

Owner

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

Before submitting

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

Area

Setup, packaging, or upgrade

Observed behavior

Source-derived complexity finding: upsertTomlServerSection scans every physical line start for every assignment, although statement traversal already advances monotonically. With N single-line assignments, the offset-to-line lookup performs N × N comparisons. This is adjacent to #4856, whose fix removes argument-count failures; it does not remove these repeated scans.

Reproduction

Inspected main c43bc0bf66a4e245a0cafa40def0d0207bcbd73c. Also ran 12 completed public rea uninstall --json invocations against isolated authored Codex configs: 8 or 10,000 distinct integer assignments followed by one REA server table, baseline versus a candidate that advances the existing line cursor. Three processes per size/revision, alternating order. Each completed, retained the exact original backup and foreign configuration, and removed REA. No target or model execution and no large stress workload.

Expected behavior

Use the existing monotonic statement traversal to identify each statement's last physical line without rescanning the entire document. Preserve unrelated source text and parsed values, including multiline values, CRLF and BOMs.

Impact and scope

The unnecessary work is established by source. End-to-end timings are noisy and do not establish a general speedup. Warm two-repeat medians for 10,000 assignments: elapsed baseline/candidate 0.538/0.520 s, reaped process-family CPU 0.817/0.744 s, sampled peak process-family RSS 371,834,880/364,306,432 bytes. For 8 assignments, elapsed 0.390/0.435 s and CPU 0.589/0.662 s. Complete normalized replies and resulting config bytes matched. No cold-cache measurements, real-client execution or broader setup-performance qualification.

REA version

c43bc0bf66

Runtime and platform

Node.js 24.18.0, macOS arm64. No analysis provider involved.

Target and artifact context

Authored local TOML configuration: 8 or 10,000 integer assignments and one REA registration.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Writer and repeated lookup at pinned revision: lineIndexAt starts at zero and scans the complete lineStarts array; its call occurs inside each assignment visit. The outer lineIndex and statement endpoints only advance. The bounded measurements above are observations, not a reproduction of a hang or capacity failure. NOT_ENOUGH_INFO for a user-visible timeout threshold.

Typed outcome or recovery expected

Existing successful uninstall result and source preservation; no new limit, refusal or caller option needed.

Analysis or suspected cause

Reuse the existing current statement index and advance through that statement's lines. No new cache/index or parser replacement is needed. Context7/DeepWiki documentation and the pinned smol-toml 1.9.0 exports confirm its public parser returns values without source spans; replacing source-preserving edits with stringify would discard formatting.

Additional context

10 ms process-family RSS sampling can miss transient/reparented peaks; sampler overhead affects elapsed time. Complete normalized reply estimates were 848 cl100k tokens in both variants, excluding requests, schemas, discovery and actual agent usage. Proposed correctness coverage includes adjacent assignments, multiline strings/arrays, empty values, BOM, CRLF and EOF without a newline. Related #4856 addresses a separate argument-spread ceiling.

Originally created by @morluto on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4873 ### 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 Setup, packaging, or upgrade ### Observed behavior Source-derived complexity finding: `upsertTomlServerSection` scans every physical line start for every assignment, although statement traversal already advances monotonically. With N single-line assignments, the offset-to-line lookup performs N × N comparisons. This is adjacent to #4856, whose fix removes argument-count failures; it does not remove these repeated scans. ### Reproduction Inspected main `c43bc0bf66a4e245a0cafa40def0d0207bcbd73c`. Also ran 12 completed public `rea uninstall --json` invocations against isolated authored Codex configs: 8 or 10,000 distinct integer assignments followed by one REA server table, baseline versus a candidate that advances the existing line cursor. Three processes per size/revision, alternating order. Each completed, retained the exact original backup and foreign configuration, and removed REA. No target or model execution and no large stress workload. ### Expected behavior Use the existing monotonic statement traversal to identify each statement's last physical line without rescanning the entire document. Preserve unrelated source text and parsed values, including multiline values, CRLF and BOMs. ### Impact and scope The unnecessary work is established by source. End-to-end timings are noisy and do not establish a general speedup. Warm two-repeat medians for 10,000 assignments: elapsed baseline/candidate 0.538/0.520 s, reaped process-family CPU 0.817/0.744 s, sampled peak process-family RSS 371,834,880/364,306,432 bytes. For 8 assignments, elapsed 0.390/0.435 s and CPU 0.589/0.662 s. Complete normalized replies and resulting config bytes matched. No cold-cache measurements, real-client execution or broader setup-performance qualification. ### REA version c43bc0bf66a4e245a0cafa40def0d0207bcbd73c ### Runtime and platform Node.js 24.18.0, macOS arm64. No analysis provider involved. ### Target and artifact context Authored local TOML configuration: 8 or 10,000 integer assignments and one REA registration. ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence [Writer and repeated lookup at pinned revision](https://github.com/morluto/rea/blob/c43bc0bf66a4e245a0cafa40def0d0207bcbd73c/src/application/ClientConfigurationDocument.ts#L982): `lineIndexAt` starts at zero and scans the complete `lineStarts` array; its call occurs inside each assignment visit. The outer `lineIndex` and statement endpoints only advance. The bounded measurements above are observations, not a reproduction of a hang or capacity failure. NOT_ENOUGH_INFO for a user-visible timeout threshold. ### Typed outcome or recovery expected Existing successful uninstall result and source preservation; no new limit, refusal or caller option needed. ### Analysis or suspected cause Reuse the existing current statement index and advance through that statement's lines. No new cache/index or parser replacement is needed. Context7/DeepWiki documentation and the pinned smol-toml 1.9.0 exports confirm its public parser returns values without source spans; replacing source-preserving edits with stringify would discard formatting. ### Additional context 10 ms process-family RSS sampling can miss transient/reparented peaks; sampler overhead affects elapsed time. Complete normalized reply estimates were 848 cl100k tokens in both variants, excluding requests, schemas, discovery and actual agent usage. Proposed correctness coverage includes adjacent assignments, multiline strings/arrays, empty values, BOM, CRLF and EOF without a newline. Related #4856 addresses a separate argument-spread ceiling.

bsakaguchi

2026-10-31 00:35:04 +00:00