Problem#

The findings-storage unit test (__tests__/findings-storage.test.ts) triggers logger.warn() and logger.error() calls during tests that test corrupt JSON handling. These write to /tmp/mission-control-app.log — the SAME log file the MC server uses.

This means every time the tests run, the MC Logs page (and log viewer) shows:

• WARN findings-storage Failed to load bad.json: SyntaxError: Unexpected token 'c', "corrupt" is not valid JSON
• ERR findings-storage Failed to load state for finding-1: SyntaxError: Unexpected token 'o', "not-json" is not valid JSON

These are NOT real errors — they are TEST artifacts that shouldn't appear in the application log.

Root cause#

findings-storage.ts imports { warn, error } from ./logger, which writes to /tmp/mission-control-app.log. During tests, the logger writes to the same global file as the MC production server. The test expects loadFindingState to gracefully handle corrupt JSON and return defaults, which it does correctly — but the error logging happens regardless of whether we're in a test context.

Fix (two options)#

Option A: Mock the logger in the test (preferred — cleanest)#

Add to __tests__/findings-storage.test.ts:

jest.mock("@/lib/logger", () => ({
  info: jest.fn(),
  warn: jest.fn(),
  error: jest.fn(),
}));

This prevents any log writes to the real file when tests exercise error paths.

Option B: Guard logger calls with JEST_WORKER_ID check#

In findings-storage.ts, wrap the error/warn calls:

if (!process.env.JEST_WORKER_ID) {
  logError("findings-storage", ...);
}

But this is less clean — library code shouldn't care about test context.

Option C: Make logger check JEST_WORKER_ID globally#

In logger.ts, if process.env.JEST_WORKER_ID is set, use a no-op: This is the defense-in-depth approach — prevents ALL logger pollution from any test.

Recommendation#

Do BOTH options A and C:

1. Mock the logger in the findings-storage test (explicit, self-documenting)
2. Add JEST_WORKER_ID guard in logger.ts (defense-in-depth, prevents future pollutions)

Also clean up the stale /tmp/mc-test-findings/ test dir (rm -rf /tmp/mc-test-findings).

Existing test dir (needs cleanup)#

• /tmp/mc-test-findings/state/ is still on disk

Tags#

[bug, tests, logger, cleanup]

Maxime's Answer#

Please finish this one

Unblock Note (auto-bulk t-3551)#

Unblocked by mass-fix on 2026-05-12 because the 3-failure deadlock logic was buggy:

• It counted gateway-outage failures (ECONNREFUSED) as task failures
• It re-blocked tasks immediately after a manual status reset
• It ignored reviewState=approved

Failure baseline set to NOW. Only failures after this timestamp count toward the next 3-strike trigger. Infra failures (ECONNREFUSED, gateway OOM) are now excluded permanently.