[diegosouzapw]

Closes #14325

Root cause

None of the 4 docker/build-push-action steps in .github/workflows/docker-publish.yml
(build, build-web, build-bun-base, build-bun-web) passed OMNIROUTE_BUILD_MEMORY_MB
in their build-args — only OMNIROUTE_USE_TURBOPACK=0. That left the Dockerfile's default
ARG OMNIROUTE_BUILD_MEMORY_MB=6144 in effect for the webpack production build
(Dockerfile:165-166), while build.yml:52 and quality.yml:133 already run the identical
npm run build/build:release on the same GitHub-hosted runner class with
OMNIROUTE_BUILD_MEMORY_MB=12288 and stay green. Since docker-publish.yml forces webpack
(OMNIROUTE_USE_TURBOPACK=0, not Turbopack), --max-old-space-size directly bounds the
process's real memory use there, so the 6144 MB ceiling is exactly what produced the
"FATAL ERROR: ... JavaScript heap out of memory" crash that has kept the :next channel
stuck at the 2026-09-17 image since 2026-09-18 16:58 UTC.

Fix

Add OMNIROUTE_BUILD_MEMORY_MB=12288 to all 4 build-args blocks in
.github/workflows/docker-publish.yml, matching the already-green budget used on the same
runner class in build.yml/quality.yml. The two bun steps use Dockerfile.bun, which
declares no OMNIROUTE_BUILD_MEMORY_MB ARG, so the addition there is a harmless no-op kept
for consistency across all 4 blocks.

Regression test

tests/unit/docker-publish-build-heap-14325.test.ts (new) reads the workflow file and
asserts every build-args block sets OMNIROUTE_BUILD_MEMORY_MB.

• RED on unfixed origin/release/v3.8.51: AssertionError: build-args block(s) at index [0,1,2,3] never override OMNIROUTE_BUILD_MEMORY_MB, so those docker/build-push-action steps build with the Dockerfile's default ARG OMNIROUTE_BUILD_MEMORY_MB=6144 heap ceiling instead of the 12288 MB that build.yml already proves fits the same runner class ... — tests 2, pass 1, fail 1.
• GREEN after the fix: tests 2, pass 2, fail 0.

Gates run

• node --import tsx/esm --test tests/unit/docker-publish-build-heap-14325.test.ts → RED then GREEN (above)
• Existing touched-area tests (docker-cache-export-best-effort-7518, build/docker-next-channel-8576, build/docker-published-image-smoke-11835, build/should-promote-latest-5301, docker-build-memory-budget, build/check-workflows, build-next-isolated, dockerfile-build-heap-4076) → 69/69 pass, none weakened
• npm run typecheck:core → exit 0, clean
• npx eslint --suppressions-location config/quality/eslint-suppressions.json tests/unit/docker-publish-build-heap-14325.test.ts → clean (no output, exit 0)
• node scripts/check/check-file-size.mjs → OK
• node scripts/check/check-complexity-ratchets.mjs --base-ref origin/release/v3.8.51 → OK, "0 changed file(s) in scope" (only a workflow YAML + a new test file touched, no source file in gate scope)
• node scripts/check/check-mutation-test-coverage.mjs --strict → OK, no drift
• node scripts/check/check-changelog-integrity.mjs → OK

Existing tests

Ran every existing test file that references docker-publish.yml or OMNIROUTE_BUILD_MEMORY_MB
(the touched area). All 69 pass unmodified; none were weakened or aligned — this change only
adds a build-arg, it does not change any behavior those tests assert on.

Validation

This is a CI/publish defect whose real fix can only be confirmed by an actual docker/build-push-action
run on the GitHub-hosted runner (local docker buildx cannot reproduce the 6-vCPU/16GB runner's
webpack heap ceiling behavior identically). The plan-file's acceptance criteria call for triggering
a manual "Publish to Docker Hub" run on release/v3.8.51 tip after merge and confirming the build
job's webpack pass completes without the V8 OOM, and that docker pull diegosouzapw/omniroute:next
picks up a fresh digest — this is left to the maintainer merging the PR, since it requires the real
CI runner.

Plan-file: _tasks/pipeline/bugs/2-implementing/14325-fix-ci-docker-next-channel-stuck-at-2026-09-17-every-publish-s.plan.md