mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-18 21:22:28 +03:00
6d99a46d4b
* fix(cli): guarantee non-empty [STARTUP] Fatal log on instrumentation-hook boot throw Refs #10171: on native Windows / WSL2 boots, an instrumentation-hook throw during module-load or registerNodejs() leaves the HTTP listener up while every DB-touching route 500s, with app.log staying completely empty. The #7773/#7828 guard in ensureDbReadyForBoot only logs one specific failure class (DB driver init). register() in src/instrumentation.ts now wraps the boot call in a try/catch at the outermost boundary and unconditionally logs a "[STARTUP] Fatal: instrumentation hook failed during boot:" line before rethrowing, so app.log/stdout is never silently empty on a failed boot regardless of platform or which step threw. This is a partial diagnostic hardening, not the full fix for #10171 — the platform-specific root cause on native Windows/WSL2 still needs the reporter's raw child stderr from a real host (tracked separately, see _tasks/pipeline/bugs/2-implementing/10171-instrumentation-hook-500-on-windows-wsl.plan.md). * fix(cli): normalize instrumentation boot errors Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * fix(cli): reuse shared normalizeBootError helper in instrumentation.ts The outermost instrumentation-hook boot boundary (#10171) was inlining its own err-instanceof-Error normalization instead of reusing the existing normalizeBootError() helper already defined in instrumentation-node.ts for the same purpose (#6560/#7773). Extract it into a dependency-free src/lib/instrumentationBootError.ts so both instrumentation.ts (which also loads under the Edge runtime) and instrumentation-node.ts can import it statically without risking a second failing dynamic import of instrumentation-node.ts from within the catch block. --------- Co-authored-by: adevwithpurpose <adevwithpurpose@users.noreply.github.com>