El build no falla cuando un Client Component importa la base: la rotura del 08:00 no se reproduce y nadie sabe que la disparo
MEDIDO por coder02 el 2026-09-05 08:13-08:18 empujando dos roturas deliberadas a dev01 (v5.4.227 y v5.4.228, control positivo de MOVILBA-261, sacado en v5.4.229). NINGUNA DE LAS DOS ROMPIO EL BUILD: 1. Un Client Component ('use client') importando @/db/connection - o sea arrastrando pg al bundle del navegador. Es LA MISMA FORMA que a las 08:00 dejo a dev01 sirviendo un build viejo con cuatro versiones sin construir. Compilo limpio y quedo sirviendo el patch 227. 2. Una pagina con export const dynamic = 'force-static' cuyo componente TIRA al renderizar, o sea que next build tiene que evaluarla al prerenderizar. Compilo limpio, patch 228. Las dos pasaron typecheck y lint, que era el punto. POR QUE IMPORTA: la falla del 08:00 se diagnostico por el import trace del pnpm-build.log (page.tsx -> lib -> db/connection -> pg) y esa lectura nombra el CAMINO pero no el DISPARADOR - porque el mismo camino, reconstruido a proposito, no rompe nada. Asi que hoy nadie sabe que condicion adicional hace fallar ese build, y 'el build lo va a agarrar' no se puede afirmar de esta clase de defecto. QUE HACE FALTA: encontrar que distingue el caso que fallo del caso que no. Sospechas a verificar, ninguna medida: si el import se usa en el cuerpo del componente en vez de solo referenciarse, si la ruta es estatica o dinamica, si el arbol de imports pasa por un archivo con 'use client' arriba de todo o por uno que solo lo hereda, y si turbopack y webpack difieren (coder03-mba-l-cc ya reporto que turbopack se niega a correr sobre el node_modules symlinkeado del worktree, asi que dev01 y el build local NO son el mismo motor). EL ARREGLO PROBABLE, y es barato: 'import server-only' en los modulos que tocan la base, para que la violacion falle en el build con un mensaje claro en vez de como cuatro built-ins de Node sin resolver - o en vez de no fallar. Hoy server-only NO es dependencia de este repo (medido por coder03-mba-l-cc el 08:03), asi que agregarla es parte del item. Levantado por nw-lezama-cc como hallazgo propio: vale un item aunque el gate de frescura ya este puesto, porque el gate detecta la caida y esto la evita. NO EJERCITADO: no se probo la forma exacta del 08:00 (el archivo intermedio src/lib/reportes/liquidacion.ts ya fue partido por coder03-mba-l-cc, asi que el original ya no existe); no se comparo webpack contra turbopack; no se leyo la config de next.
Activity
-
PISTA de bin-lezama-cc, 2026-09-05 08:23, LEIDA de la config y NO probada: next.config.ts en dev declara serverExternalPackages: ['bcryptjs','pg'] y aliasea pg-native a false. Eso le dice a Next que deje pg EXTERNO en vez de resolverlo dentro de un bundle, y es una razon plausible de que mi import deliberado desde un Client Component compile limpio. Es una pista para probar, no la respuesta - y no explica por si sola que si fallo a las 08:00 por el mismo camino. Sigue en pie el punto del motor: turbopack se niega a correr sobre el node_modules symlinkeado del worktree (medido por coder03-mba-l-cc), asi que un build local y el de dev01 no son el mismo motor y una conclusion sacada del local esta corta un motor.
-
coder03-mba-l-cc / coder
-
coder03assistant-mba-l-ca
-
coder03assistant-mba-l-ca | 2026-09-28 13:49 ART — Added the server-only boundary to src/db/connection.ts and pinned server-only 0.0.1 in package.json, pnpm-lock.yaml, and package-lock.json. This guards the central pg/Drizzle connection import path. No build/test/browser reproduction run per current coding handoff rule; exact original 08:00 import chain and Turbopack-vs-Webpack distinction remain unexercised. Sent diff to audit-mba-l-cc; awaiting verdict.
-
audit fail: Ran typecheck (green), test:source (2 new failures). Confirmed via git stash bisection: reverting the diff fixes both.
payload
{"scope":"Ran typecheck (green), test:source (2 new failures). Confirmed via git stash bisection: reverting the diff fixes both.","outcome":"fail","evidence":"'import server-only' in src/db/connection.ts throws unconditionally under tsx --test (node_modules/server-only/index.js:1, 'cannot be imported from a Client Component'), crashing dropdowns-batch.test.ts and health-probes.test.ts, which import db/connection outside Next's bundler.","reportRef":null} -
coder03assistant-mba-l-ca | 2026-09-28 13:55 ART — Audit FAIL confirmed the bare server-only import crashes two Node source tests that load DB-backed routes. Updated test boundaries without weakening the marker: moved dropdown batching into a DB-free helper and moved the readiness handler logic into a DB-free module; their tests now import those helpers rather than importing routes with src/db/connection. Implementation still requires audit rerun; no lint/typecheck/tests/build run by this lane.
-
audit pass: Rerun on the live tree: server-only import confirmed back in src/db/connection.ts, pinned in package.json/lockfiles. typecheck green, test:source 38/38 green including dropdowns-batch and health-probes explicitly.
payload
{"scope":"Rerun on the live tree: server-only import confirmed back in src/db/connection.ts, pinned in package.json/lockfiles. typecheck green, test:source 38/38 green including dropdowns-batch and health-probes explicitly.","outcome":"pass","evidence":"Direct rerun of the two previously-failing test files passes standalone; batch.ts/readiness-handler.ts unchanged from prior review (DB-free, no server-only conflict).","reportRef":null} -
coder03assistant-mba-l-ca | 2026-09-28 14:09 ART — Added createRequire(filename) in tools/tests/colectivo-owner-options.test.cjs so relative imports from the transformed dropdown route resolve from src/app/api/dropdowns/ rather than tools/tests/. The batch helper remains src/app/api/dropdowns/batch.ts. This addresses the reported MODULE_NOT_FOUND in test:tools; no local test run per standing handoff rule. Requesting audit of the test:tools gate and this harness fix.
-
audit pass: test:tools full gate (101/101) + standalone colectivo-owner-options.test.cjs (3/3) after createRequire fix
payload
{"scope":"test:tools full gate (101/101) + standalone colectivo-owner-options.test.cjs (3/3) after createRequire fix","outcome":"pass","evidence":"no MODULE_NOT_FOUND, tools/tests/colectivo-owner-options.test.cjs resolves ./batch via createRequire(route filename), full suite green","reportRef":null} -
coder03-mba-l-cc 2026-09-28 14:25 ART - the handler extraction shipped; 'import server-only' did NOT and must not come back as-is. SHIPPED (v5.6.96-v5.6.98, dev+main): src/app/api/dropdowns/batch.ts, src/app/health/readiness-handler.ts and their tests, plus the harness fix below. REVERTED: 'import server-only' in src/db/connection.ts and the server-only dependency. Turbopack aborts the WHOLE build on it - src/lib/logger.ts pulls connection.ts into a Client Component SSR graph via src/app/not-found.tsx, and it also enters as Middleware through src/proxy.ts. v5.6.96 and v5.6.97 were pushed and never built because of it. The guard is only viable after logger.ts is decoupled from connection.ts; the condition is written in-file at src/db/connection.ts:4. Two gate findings, both structural: 1. NO SHIP PATH RUNS 'next build'. mba-deploy-dev.sh = test:source + lint + typecheck; mba-deploy-prod.sh = lockfiles + typecheck + test:source. Only the bare's post-receive hook builds, AFTER the push. Neither an audit PASS nor the deploy gates could have caught this - it is not a lane error, it is a missing gate. 2. The audit PASS cited test:source 38/38 for a change whose breakage was in test:tools. test:tools was red twice in a row on this item: first tools/tests/colectivo-owner-options.test.cjs MODULE_NOT_FOUND on require('./batch'), then tools/tests/colectivo-estado-catalogo.test.mjs on server-only. --scope must name the suite that covers the changed file, not the suite that was convenient. Also fixed: pnpm-lock.yaml carried server-only in 'importers' with NO entry in 'packages' or 'snapshots' - a hand-edited lockfile, not a resolved one. The remote install died with ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY. Lockfiles are regenerated with pnpm/npm, never edited. Harness fix (tools/tests/colectivo-owner-options.test.cjs): the VM require shim resolved a relative specifier against the TEST file's directory, so the moment route.ts was split into sibling modules './batch' was looked for in tools/tests/. Now resolved with createRequire(routeFilename). test:tools also runs with --conditions=react-server, which is how Next resolves server-only's exports map. test:source 38/38, test:tools 101/101, typecheck and local build green. dev and main both at v5.6.100.
-
audit pass: verified the server-only revert (cd06cacc) actually fixes the build: ran pnpm build clean on HEAD=739cae7d, full route manifest emitted, exit 0
payload
{"scope":"verified the server-only revert (cd06cacc) actually fixes the build: ran pnpm build clean on HEAD=739cae7d, full route manifest emitted, exit 0","outcome":"pass","evidence":"pnpm build exit 0, no Turbopack abort; confirms coder03's claim that no ship path runs next build and the fix must be verified manually until that gate exists","reportRef":null} -
coder03assistant-mba-l-ca | 2026-10-01 23:42 ART. The server-only marker was reverted because it broke the production build; audit verified the revert and a clean pnpm build on HEAD 739cae7d. The outstanding preventative build-gate requirement is tracked by MOVILBA-612; that item carries the gate work.