[GH-ISSUE #4931] [Bug] TOML setup scans internal blank-line runs quadratically #3058

Closed
opened 2026-10-31 00:35:41 +00:00 by bsakaguchi · 0 comments
Owner

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

Before submitting

  • I searched open and closed issues; #4856 is related but fixed an argument-spread limit rather than this scan cost.
  • The fixture is authored local data and contains no credentials or sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

The 140,000-line Codex TOML setup/uninstall acceptance workflow times out at 30 seconds on main CI and locally. Grok's comment-line control passes.

Reproduction

On Linux with the pinned toolchain, run:

npm run test:focused -- tests/acceptance/setup/tomlConfigurationCapacityCli.test.ts

Local result: Codex timed out at 30,136 ms, Grok passed at 15,913 ms; 1 failed / 1 passed. The input is model = "local-control", 140,000 LF blank lines, then an unrelated [mcp_servers.other] registration. The test performs preview, apply, idempotent reapply, and uninstall.

Expected behavior

Preserve unrelated TOML text, backup contents, and registrations while completing setup and uninstall with work proportional to the document size. Preserve the existing capacity test and its timeout.

Impact and scope

Confirmed Linux Codex setup performance and main CI capacity coverage. Other sizes and platforms have not been measured yet. No observed evidence of data loss.

REA version

Local reproduction at 17f9764a5143009a4e8645e9965a2deca443d5d9, whose product source is main bbfe6edd60290f9bfbec68c8a0bcf605d8bbf5b3; its three test-only maintenance changes do not touch TOML. Main 2183c9598 independently fails the same acceptance case.

Runtime and platform

Linux x64, Node 24.18.0, npm 11.16.0. Local commands were limited to two CPUs and stayed below 1 GiB sampled family RSS for this workflow.

Target and artifact context

Authored local TOML client configuration; no disassembler or external target required.

Interface

CLI / Package or setup

Earliest failure stage

Setup or provider admission

Relevant output or evidence

codex setup and uninstall preserve large valid TOML documents — Test timed out in 30000ms both on main CI and locally. A completed direct serializer call on the same 140,000-LF input took 26.8 s wall / 26.6 s CPU and preserved the expected parsed values.

Analysis or suspected cause

The shared TOML serializer removes trailing LF using an unanchored \n+$ regex. It retries long internal LF runs that are followed by non-newline content. A diagnostic CPU profile attributes approximately 31.2 s of one execution to that regex. A reverse scan for terminal LF can avoid the repeated work while preserving exact formatting semantics.

Additional context

Follow-up to #4856. The shared implementation is the correction point; reducing the 140,000-line fixture or raising the test timeout would hide the cost.

Originally created by @N0zoM1z0 on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4931 ### Before submitting - [x] I searched open and closed issues; #4856 is related but fixed an argument-spread limit rather than this scan cost. - [x] The fixture is authored local data and contains no credentials or sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior The 140,000-line Codex TOML setup/uninstall acceptance workflow times out at 30 seconds on [main CI](https://github.com/morluto/rea/actions/runs/39083000773/job/117545198441) and locally. Grok's comment-line control passes. ### Reproduction On Linux with the pinned toolchain, run: ```sh npm run test:focused -- tests/acceptance/setup/tomlConfigurationCapacityCli.test.ts ``` Local result: Codex timed out at 30,136 ms, Grok passed at 15,913 ms; 1 failed / 1 passed. The input is `model = "local-control"`, 140,000 LF blank lines, then an unrelated `[mcp_servers.other]` registration. The test performs preview, apply, idempotent reapply, and uninstall. ### Expected behavior Preserve unrelated TOML text, backup contents, and registrations while completing setup and uninstall with work proportional to the document size. Preserve the existing capacity test and its timeout. ### Impact and scope Confirmed Linux Codex setup performance and main CI capacity coverage. Other sizes and platforms have not been measured yet. No observed evidence of data loss. ### REA version Local reproduction at `17f9764a5143009a4e8645e9965a2deca443d5d9`, whose product source is main `bbfe6edd60290f9bfbec68c8a0bcf605d8bbf5b3`; its three test-only maintenance changes do not touch TOML. Main `2183c9598` independently fails the same acceptance case. ### Runtime and platform Linux x64, Node 24.18.0, npm 11.16.0. Local commands were limited to two CPUs and stayed below 1 GiB sampled family RSS for this workflow. ### Target and artifact context Authored local TOML client configuration; no disassembler or external target required. ### Interface CLI / Package or setup ### Earliest failure stage Setup or provider admission ### Relevant output or evidence `codex setup and uninstall preserve large valid TOML documents` — `Test timed out in 30000ms` both on main CI and locally. A completed direct serializer call on the same 140,000-LF input took 26.8 s wall / 26.6 s CPU and preserved the expected parsed values. ### Analysis or suspected cause The shared [TOML serializer](https://github.com/morluto/rea/blob/bbfe6edd60290f9bfbec68c8a0bcf605d8bbf5b3/src/application/ClientConfigurationDocument.ts#L1117) removes trailing LF using an unanchored `\n+$` regex. It retries long internal LF runs that are followed by non-newline content. A diagnostic CPU profile attributes approximately 31.2 s of one execution to that regex. A reverse scan for terminal LF can avoid the repeated work while preserving exact formatting semantics. ### Additional context Follow-up to #4856. The shared implementation is the correction point; reducing the 140,000-line fixture or raising the test timeout would hide the cost.
bsakaguchi 2026-10-31 00:35:41 +00:00
  • closed this issue
  • added the
    triage
    bug
    labels
Sign in to join this conversation.
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#3058
No description provided.