Diego Rodrigues de Sa e Souza 858598a200 fix(db): stop legacy log-archive migration from deleting the live app-logger directory and crashing startup on a stat/stream race (#6401) (#6898) ...

archiveLegacyRequestLogs() swept the entire DATA_DIR/logs directory as a
single "legacy" target and recursively deleted it after zipping. Since
PR #6234 moved the default app-log path to DATA_DIR/logs/application,
the migration was deleting the live file logger's own directory on
every boot until its marker file existed (#6799).

Separately, yazl's addFile() does an internal stat-then-stream read; if
a target file grows between those two steps (e.g. an actively-written
log), yazl emits "error" directly on the ZipFile instance. That event
had no listener, so Node re-threw it as an uncaughtException that
crashed the whole process at startup (#6401) — misdiagnosed upstream as
Turbopack/Windows chunk corruption because the stack trace pointed into
a bundled chunk.

Fix:
- listArchiveTargets() now enumerates DATA_DIR/logs entries individually
  and skips the live app-logger directory (resolved via
  logEnv.getAppLogFilePath()), so the shared parent directory is never
  deleted wholesale.
- createLegacyArchive() wires a zipFile.on("error", ...) handler so a
  stat/stream race rejects the promise (caught by the existing
  try/catch) instead of escaping as an uncaughtException.

Regression test: tests/unit/usage-migrations-legacy-archive-safety.test.ts
(RED on unfixed code, GREEN after fix). Updated
tests/unit/request-log-migration.test.ts to the corrected contract —
DATA_DIR/logs itself now survives the archive sweep.

Gates run clean: file-size, complexity, cognitive-complexity,
changelog-integrity, typecheck:core, eslint (suppressions), and the
existing usage-migrations/request-log-migration unit suites.

2026-07-12 02:00:02 -03:00

3.5 KiB

Raw Blame History

View Raw