morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #5077] [Bug] Error catalogue marks a removed 64 MiB process-input limit as implemented #3112

New issue

Closed

opened 2026-10-31 00:36:47 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-31 00:36:47 +00:00

Owner

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

Before submitting

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

Area

Documentation

Observed behavior

SOURCE-ONLY. docs/user-visible-errors.csv row 62 says a process scenario or Evidence file exceeding 64 MiB produces “Process input file is too large. Reduce it below 64 MiB, then try again.” It marks this behavior implemented and records verification by a focused sparse-file CLI test.

The current process CLI delegates to the shared JSON reader, which explicitly accepts larger files through streaming and admits retained JSON values against live heap headroom. The documented replacement has no match in the TypeScript source. No REA runtime was executed.

Reproduction

At source revision 3537e58c1ab29309f06eabf50bc52adba9817a0c, run this read-only comparison from the checkout root:

python3 - <<'CHECK'
import csv
from pathlib import Path
with open("docs/user-visible-errors.csv", newline="") as stream:
    row = next(r for r in csv.DictReader(stream)
               if r["location"] == "src/application/process/ProcessCli.ts:readJson size")
print(row["trigger"], row["implementation_status"])
print(row["proposed_replacement"])
print("source matches:", sum(row["proposed_replacement"] in p.read_text()
                             for p in Path("src").rglob("*.ts")))
CHECK

Observed: Process scenario or evidence file exceeds 64 MiB implemented, the replacement quoted above, and source matches: 0.

Then follow the pinned source path below. It uses an 8 MiB native-parser selection budget with a streaming fallback and live memory admission, rather than the documented 64 MiB rejection. No large fixture or heap-exhaustion experiment is needed for this documentation comparison.

Expected behavior

The catalogue should describe the current input policy and recovery text, or explicitly identify superseded behavior. An implemented row with a verification claim should not present a removed fixed-size boundary as current behavior. This report does not request reintroducing that boundary.

Impact and scope

Documentation wording/cleanup affecting readers auditing process-input errors. No runtime failure, data loss, or behavior change was established. Readers can inspect the shared JSON reader for the current policy. Readership and ordinary-use frequency are NOT_ENOUGH_INFO.

REA version

Source baseline 3537e58c1ab29309f06eabf50bc52adba9817a0c, package version 6.7.0. Relevant files are unchanged from stable tag rea-agents-6.7.0 at 27dc42d10249f0410904a75c0997842eb03b931c. Published stable runtime was not executed.

Runtime and platform

Static inspection: Node v26.12.0, Darwin 27.0.0, arm64. No REA runtime or provider was exercised.

Target and artifact context

The tracked error catalogue and process JSON input implementation; no executable target or input fixture.

Interface

CLI

Earliest failure stage

Unknown

Relevant output or evidence

Catalogue row marked implemented.
CLI registration and supported file callers.
Process input reader and error projection delegate to readJsonFile; no fixed-size branch appears.
Shared reader delegation and resource-error preservation.
8 MiB implementation selection, with larger files streamed, native-or-streaming execution, and live heap admission.

Evidence is a static documentation/source comparison. Exact runtime output for an input over 64 MiB is NOT_ENOUGH_INFO and was not tested.

Typed outcome or recovery expected

Document the current typed resource-admission policy and recovery guidance rather than the removed size-policy message. No runtime outcome change is requested.

Analysis or suspected cause

Source-derived: the catalogue and current JSON reader disagree. Why the row was retained is NOT_ENOUGH_INFO; no history analysis was performed.

Additional context

No existing open or closed report covering this catalogue row and removed size boundary was found in the issue snapshot searched. No provider, external API, build, or runtime test was used.

Originally created by @coygeek on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5077 ## 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 Documentation ## Observed behavior SOURCE-ONLY. `docs/user-visible-errors.csv` row 62 says a process scenario or Evidence file exceeding 64 MiB produces “Process input file is too large. Reduce it below 64 MiB, then try again.” It marks this behavior `implemented` and records verification by a focused sparse-file CLI test. The current process CLI delegates to the shared JSON reader, which explicitly accepts larger files through streaming and admits retained JSON values against live heap headroom. The documented replacement has no match in the TypeScript source. No REA runtime was executed. ## Reproduction At source revision `3537e58c1ab29309f06eabf50bc52adba9817a0c`, run this read-only comparison from the checkout root: ```sh python3 - <<'CHECK' import csv from pathlib import Path with open("docs/user-visible-errors.csv", newline="") as stream: row = next(r for r in csv.DictReader(stream) if r["location"] == "src/application/process/ProcessCli.ts:readJson size") print(row["trigger"], row["implementation_status"]) print(row["proposed_replacement"]) print("source matches:", sum(row["proposed_replacement"] in p.read_text() for p in Path("src").rglob("*.ts"))) CHECK ``` Observed: `Process scenario or evidence file exceeds 64 MiB implemented`, the replacement quoted above, and `source matches: 0`. Then follow the pinned source path below. It uses an 8 MiB native-parser selection budget with a streaming fallback and live memory admission, rather than the documented 64 MiB rejection. No large fixture or heap-exhaustion experiment is needed for this documentation comparison. ## Expected behavior The catalogue should describe the current input policy and recovery text, or explicitly identify superseded behavior. An `implemented` row with a verification claim should not present a removed fixed-size boundary as current behavior. This report does not request reintroducing that boundary. ## Impact and scope Documentation wording/cleanup affecting readers auditing process-input errors. No runtime failure, data loss, or behavior change was established. Readers can inspect the shared JSON reader for the current policy. Readership and ordinary-use frequency are NOT_ENOUGH_INFO. ## REA version Source baseline `3537e58c1ab29309f06eabf50bc52adba9817a0c`, package version 6.7.0. Relevant files are unchanged from stable tag `rea-agents-6.7.0` at `27dc42d10249f0410904a75c0997842eb03b931c`. Published stable runtime was not executed. ## Runtime and platform Static inspection: Node v26.12.0, Darwin 27.0.0, arm64. No REA runtime or provider was exercised. ## Target and artifact context The tracked error catalogue and process JSON input implementation; no executable target or input fixture. ## Interface CLI ## Earliest failure stage Unknown ## Relevant output or evidence - [Catalogue row marked implemented](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/docs/user-visible-errors.csv#L75). - [CLI registration and supported file callers](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/cli/processCommands.ts#L19-L55). - [Process input reader and error projection](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/process/ProcessCli.ts#L212-L235) delegate to `readJsonFile`; no fixed-size branch appears. - [Shared reader delegation](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/JsonFiles.ts#L42-L55) and [resource-error preservation](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/JsonFiles.ts#L96-L130). - [8 MiB implementation selection, with larger files streamed](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/JsonInputFile.ts#L30-L43), [native-or-streaming execution](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/JsonInputFile.ts#L243-L303), and [live heap admission](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/JsonInputFile.ts#L424-L474). Evidence is a static documentation/source comparison. Exact runtime output for an input over 64 MiB is NOT_ENOUGH_INFO and was not tested. ## Typed outcome or recovery expected Document the current typed resource-admission policy and recovery guidance rather than the removed size-policy message. No runtime outcome change is requested. ## Analysis or suspected cause Source-derived: the catalogue and current JSON reader disagree. Why the row was retained is NOT_ENOUGH_INFO; no history analysis was performed. ## Additional context No existing open or closed report covering this catalogue row and removed size boundary was found in the issue snapshot searched. No provider, external API, build, or runtime test was used.

bsakaguchi closed this issue

2026-10-31 00:36:47 +00:00

bsakaguchi commented

2026-10-31 00:36:47 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

Claiming this one — I'll align the user-visible-errors.csv row with the actual streaming/heap-headroom behavior and add a catalogue↔source consistency regression test.

@akushonkamen commented on GitHub (Oct 19, 2026): Claiming this one — I'll align the `user-visible-errors.csv` row with the actual streaming/heap-headroom behavior and add a catalogue↔source consistency regression test.

bsakaguchi commented

2026-10-31 00:36:48 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 19, 2026):

Progress update — fix is ready on a fork branch (PR creation is deferred this round):

Branch: https://github.com/akushonkamen/rea/tree/fix/5077-error-catalogue-64mib (commit 736763b42)
docs/user-visible-errors.csv:75 (row 62): the readJson size row is now marked removed and documents the superseded 64 MiB boundary, matching the shared-reader streaming / live heap-headroom input policy.
New regression test tests/boundary/process/userVisibleErrorsCatalog.test.ts fails when any implemented catalogue row cites a byte-size limit with no match in the process input reader, and pins the readJson size row to a non-implemented status. Verified red before the fix (2 failed) and green after (2 passed); --project boundary shows the same pre-existing environment failures (82 failed / 386 passed) with and without this change.
Commit message ends with Fixes #5077; happy for a maintainer to open the PR from this branch or for me to open one once PR creation is unblocked.

@akushonkamen commented on GitHub (Oct 19, 2026): Progress update — fix is ready on a fork branch (PR creation is deferred this round): - **Branch:** https://github.com/akushonkamen/rea/tree/fix/5077-error-catalogue-64mib (commit 736763b42) - `docs/user-visible-errors.csv:75` (row 62): the `readJson size` row is now marked `removed` and documents the superseded 64 MiB boundary, matching the shared-reader streaming / live heap-headroom input policy. - New regression test `tests/boundary/process/userVisibleErrorsCatalog.test.ts` fails when any `implemented` catalogue row cites a byte-size limit with no match in the process input reader, and pins the `readJson size` row to a non-implemented status. Verified red before the fix (2 failed) and green after (2 passed); `--project boundary` shows the same pre-existing environment failures (82 failed / 386 passed) with and without this change. - Commit message ends with `Fixes #5077`; happy for a maintainer to open the PR from this branch or for me to open one once PR creation is unblocked.

bsakaguchi commented

2026-10-31 00:36:48 +00:00

Author

Owner

@xu91102 commented on GitHub (Oct 20, 2026):

Confirmed on current main 074768901f3cdc8205b61773fb1faf6f6c7b3ca8. CSV row 62 still describes an implemented fixed 64 MiB process-input refusal and claims a sparse-file CLI test.

I also ran two real compiled CLI controls with rea capture-process <scenario.json> --json --full-output: a two-byte {} file and a 67,108,867-byte file containing whitespace followed by the same {}. Both reached scenario validation and returned the same invalid_request / missing executable issue, rather than a fixed-size error. Both file hashes remained unchanged; no child process was launched because the scenario was invalid.

The correction will only update the catalogue's obsolete size-policy row to describe the current shared reader's heap-based resource admission and distinguish source inspection from the executed large-file control. It will not restore a 64 MiB limit or change runtime behavior. Heap exhaustion, a successful large scenario execution, published package and Windows/Linux were not tested.

Follow-up after implementation: the fix is a single CSV row, committed normally to xu91102/rea as e6ec7454a2b335e5db20cbd59e612557d29ea7ca (codex/process-error-catalog, based on 074768901). All other catalogue records are unchanged. The replacement remediation is byte-for-byte the production JSON_INPUT_RESOURCE_REMEDIATION constant. npm run check, npm run docs:check (5 fresh README tests), and separate independent Standards/Spec reviews pass. Normal hooks and fork push completed; the frozen patch bytes match after commit/push.

There is no upstream PR or upstream CI for this change yet. No repeated create request was made while the previously observed creation refusal has no confirmed recovery. The two CLI probes demonstrate JSON reading reaches schema validation; they do not demonstrate successful process capture or heap-exhaustion handling. No issue-close action was made.

Publication follow-up after renewed author instruction: the first prepared item in this batch, #5386 (xu91102:codex/grpc-web-trailer-values → morluto/rea:main, Draft), was actually attempted through ordinary gh pr create on 2026-10-20. GitHub returned xu91102 does not have the correct permissions to execute CreatePullRequest. The exact-head follow-up query found no PR. Cause/policy are unknown; no account/API/UI bypass or self-closing another PR was used. The remaining two branch requests were not repeated after the same refusal. This batch still has zero upstream PRs, so these new items have no upstream CI or Codex PR review yet. Existing fork commits and validation remain as documented above.

Main coverage update (2026-10-21)

Main commit 82902465c now fixes this report's core issue. I read the actual change and confirmed it is included in captured main d0067ba34a39ea47dd7e11bb2e6169bc0938cc3f. My unsubmitted fork preparation is now on read-only HOLD to avoid a duplicate PR. I have not run the main fix through the complete original workflow, and do not transfer the fork's validation results to main or claim source adoption or author credit. No upstream PR was created from my branch.

@xu91102 commented on GitHub (Oct 20, 2026): Confirmed on current main `074768901f3cdc8205b61773fb1faf6f6c7b3ca8`. CSV row 62 still describes an implemented fixed 64 MiB process-input refusal and claims a sparse-file CLI test. I also ran two real compiled CLI controls with `rea capture-process <scenario.json> --json --full-output`: a two-byte `{}` file and a 67,108,867-byte file containing whitespace followed by the same `{}`. Both reached scenario validation and returned the same `invalid_request` / missing `executable` issue, rather than a fixed-size error. Both file hashes remained unchanged; no child process was launched because the scenario was invalid. The correction will only update the catalogue's obsolete size-policy row to describe the current shared reader's heap-based resource admission and distinguish source inspection from the executed large-file control. It will not restore a 64 MiB limit or change runtime behavior. Heap exhaustion, a successful large scenario execution, published package and Windows/Linux were not tested. Follow-up after implementation: the fix is a single CSV row, committed normally to `xu91102/rea` as `e6ec7454a2b335e5db20cbd59e612557d29ea7ca` (`codex/process-error-catalog`, based on `074768901`). All other catalogue records are unchanged. The replacement remediation is byte-for-byte the production `JSON_INPUT_RESOURCE_REMEDIATION` constant. `npm run check`, `npm run docs:check` (5 fresh README tests), and separate independent Standards/Spec reviews pass. Normal hooks and fork push completed; the frozen patch bytes match after commit/push. There is no upstream PR or upstream CI for this change yet. No repeated create request was made while the previously observed creation refusal has no confirmed recovery. The two CLI probes demonstrate JSON reading reaches schema validation; they do not demonstrate successful process capture or heap-exhaustion handling. No issue-close action was made. Publication follow-up after renewed author instruction: the first prepared item in this batch, #5386 (`xu91102:codex/grpc-web-trailer-values` → `morluto/rea:main`, Draft), was actually attempted through ordinary `gh pr create` on 2026-10-20. GitHub returned `xu91102 does not have the correct permissions to execute CreatePullRequest`. The exact-head follow-up query found no PR. Cause/policy are unknown; no account/API/UI bypass or self-closing another PR was used. The remaining two branch requests were not repeated after the same refusal. This batch still has zero upstream PRs, so these new items have no upstream CI or Codex PR review yet. Existing fork commits and validation remain as documented above. ### Main coverage update (2026-10-21) Main commit [82902465c](https://github.com/morluto/rea/commit/82902465c45f71dfc420c2e0a35f528a2ab8ba85) now fixes this report's core issue. I read the actual change and confirmed it is included in captured main `d0067ba34a39ea47dd7e11bb2e6169bc0938cc3f`. My unsubmitted fork preparation is now on read-only HOLD to avoid a duplicate PR. I have not run the main fix through the complete original workflow, and do not transfer the fork's validation results to main or claim source adoption or author credit. No upstream PR was created from my branch.

bsakaguchi commented

2026-10-31 00:36:48 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 20, 2026):

TL;DR: This looks fixed on main. Closing is the maintainers' call.

Checked on main b3aadaf47 (Linux, Node 24.18.0). Row 62 of docs/user-visible-errors.csv no longer promises a 64 MiB refusal. It now says heap admission depends on live runtime capacity. It calls the fixed limit superseded. This matches the fix in 82902465c.

Not run

The process CLI with a large file. This was a source check only.

Thanks, coygeek, for the clear report.

Commands

grep -n "64 MiB" docs/user-visible-errors.csv

Exit 0, one hit, line 75 (row 62): "Heap admission depends on live runtime capacity rather than a fixed 64 MiB file limit" ... "former fixed-size refusal is superseded". The row status still reads implemented, now for the heap check.

Test setup

Box: Nobara 44 (Fedora 44 base), Linux 7.2.11
CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
RAM: 32 GB DDR4-3600
Node: 24.18.0
Head: b3aadaf47
Other: another job shared the box during the run

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 20, 2026): **TL;DR:** This looks fixed on main. Closing is the maintainers' call. Checked on main b3aadaf47 (Linux, Node 24.18.0). Row 62 of `docs/user-visible-errors.csv` no longer promises a 64 MiB refusal. It now says heap admission depends on live runtime capacity. It calls the fixed limit superseded. This matches the fix in 82902465c. ### Not run - The process CLI with a large file. This was a source check only. Thanks, coygeek, for the clear report. <details> <summary>Commands</summary> ```sh grep -n "64 MiB" docs/user-visible-errors.csv ``` Exit 0, one hit, line 75 (row 62): "Heap admission depends on live runtime capacity rather than a fixed 64 MiB file limit" ... "former fixed-size refusal is superseded". The row status still reads `implemented`, now for the heap check. </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.11 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - RAM: 32 GB DDR4-3600 - Node: 24.18.0 - Head: b3aadaf47 - Other: another job shared the box during the run </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

bsakaguchi commented

2026-10-31 00:36:48 +00:00

Author

Owner

@morluto commented on GitHub (Oct 21, 2026):

Closing as fixed on main by github.com/morluto/rea@82902465c4, retained at 67a6477f01.

The error catalogue now documents shared live-heap JSON admission and explicitly marks the former fixed 64 MiB refusal as superseded. The row's recovery text and verification attribution match the owning shared reader. This is a documentation/source-consistency closure, not a new large capture or heap-exhaustion claim.

This closure follows current-main producer and regression source inspection and the existing issue evidence. Tests and runtime reproductions were not rerun in this audit; no additional platform/provider coverage is implied.

@morluto commented on GitHub (Oct 21, 2026): Closing as fixed on main by https://github.com/morluto/rea/commit/82902465c45f71dfc420c2e0a35f528a2ab8ba85, retained at 67a6477f011ae358fc333e5a6e26c86d932654ed. The error catalogue now documents shared live-heap JSON admission and explicitly marks the former fixed 64 MiB refusal as superseded. The row's recovery text and verification attribution match the owning shared reader. This is a documentation/source-consistency closure, not a new large capture or heap-exhaustion claim. This closure follows current-main producer and regression source inspection and the existing issue evidence. Tests and runtime reproductions were not rerun in this audit; no additional platform/provider coverage is implied.

bsakaguchi referenced this issue

2026-10-31 01:08:04 +00:00

[PR #3112] [MERGED] docs(release): review compatibility for the current candidate #5625

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#3112

No description provided.

Rows
Columns