[GH-ISSUE #1805] build: strict Turbo tasks drop caller resource controls #608

New issue

Closed

opened 2026-10-15 18:26:36 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:36 +00:00

Owner

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

On main ed084b3dbb13ec9dee1adc8f5b76e784b52c00bb, the default strict Turbo 2.11.7 task environment drops caller-selected GOMAXPROCS, GOMEMLIMIT, and UV_THREADPOOL_SIZE. A caller limiting Go compiler concurrency, Go memory, or the Node worker pool therefore loses those settings inside cached task execution.

An actual child-process probe using the installed, pinned Turbo and REA's unchanged configuration set GOMAXPROCS=1, GOMEMLIMIT=384MiB, and UV_THREADPOOL_SIZE=2. The task observed all three as absent. NODE_OPTIONS=--max-old-space-size=384 remained available, so this report does not claim that Node heap settings are dropped.

The producing boundary is Turbo's strict environment filtering, not REA's runtime adapters. The intended fix is to pass through these three resource-only controls without changing cache keys or switching the repository to loose environment mode. A regression should exercise the real cached-build task graph with a small compiler fixture, check that an unrelated environment variable remains filtered, and verify that changing only resource settings still reuses the cache.

Earlier profiled builds exceeded a 2 GiB process-family budget, but the profiling boundary did not forward the outer wrapper’s resource settings to its workload. Those runs do not establish the memory effect of this configuration change. This issue is based on the independently reproduced task-environment defect.

Related resource-maintenance context: #1065. No external repository changes are required.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1805 On main `ed084b3dbb13ec9dee1adc8f5b76e784b52c00bb`, the default strict Turbo 2.11.7 task environment drops caller-selected `GOMAXPROCS`, `GOMEMLIMIT`, and `UV_THREADPOOL_SIZE`. A caller limiting Go compiler concurrency, Go memory, or the Node worker pool therefore loses those settings inside cached task execution. An actual child-process probe using the installed, pinned Turbo and REA's unchanged configuration set `GOMAXPROCS=1`, `GOMEMLIMIT=384MiB`, and `UV_THREADPOOL_SIZE=2`. The task observed all three as absent. `NODE_OPTIONS=--max-old-space-size=384` remained available, so this report does not claim that Node heap settings are dropped. The producing boundary is Turbo's strict environment filtering, not REA's runtime adapters. The intended fix is to pass through these three resource-only controls without changing cache keys or switching the repository to loose environment mode. A regression should exercise the real cached-build task graph with a small compiler fixture, check that an unrelated environment variable remains filtered, and verify that changing only resource settings still reuses the cache. Earlier profiled builds exceeded a 2 GiB process-family budget, but the profiling boundary did not forward the outer wrapper’s resource settings to its workload. Those runs do not establish the memory effect of this configuration change. This issue is based on the independently reproduced task-environment defect. Related resource-maintenance context: #1065. No external repository changes are required.

bsakaguchi

2026-10-15 18:26:36 +00:00