⚠️ Skipping ${file}: report #${reportNum} is marked "failed

Error message

⚠️  Skipping ${file}: report #${reportNum} is marked "failed" in batch-state.tsv — refusing to merge a tracker line for an offer the batch runner itself recorded as failed (possible fabricated result)

What it means

Safety gate in merge-tracker.mjs against fabricated batch results: the batch runner records failed evaluations by report number in batch-state.tsv, and those numbers are loaded into FAILED_REPORT_NUMBERS. If an additions file cites one of those report numbers, the tracker line is refused — a worker that failed cannot legitimately have produced a tracker row for that offer.

Source

Thrown at merge-tracker.mjs:1018

  // The TSV convention carries a root-relative `reports/...` link; rewrite it
  // so it resolves correctly when clicked from applications.md (see #760).
  addition.report = normalizeReportLink(addition.report);

  // Derive the key from the linked report when the TSV did not carry one, so a
  // row added through the normal nine-column flow is born WITH its key. This
  // must run before the dedup below reads addition.url — deriving it afterwards
  // would populate the column while leaving Pass 0 nothing to match on, which is
  // the original bug with extra steps.
  if (!addition.url) addition.url = resolveReportUrl(addition.report).url;

  // Check for duplicate by:
  // 0. Exact normalized posting URL (deterministic, authoritative)
  // 1. Exact report number match
  // 2. Company + role fuzzy match
  const reportNum = extractReportNum(addition.report, addition.notes);

  if (reportNum && FAILED_REPORT_NUMBERS.has(reportNum)) {
    console.warn(`⚠️  Skipping ${file}: report #${reportNum} is marked "failed" in batch-state.tsv — refusing to merge a tracker line for an offer the batch runner itself recorded as failed (possible fabricated result)`);
    skipped++;
    continue;
  }

  let duplicate = null;
  // True only for a tier-1 match (report number + company): the one heuristic
  // tier where the addition is provably the same evaluation as the existing
  // row, so its role title may replace the row's. Tier-2 (entry num) and
  // tier-3 (fuzzy role) matches keep the existing title — a fuzzy false
  // positive that also rewrites the title destroys the evidence that two reqs
  // were distinct. Pass 0 (URL) grants the same trust for the same reason; it
  // tracks that separately in `dupReason`.
  let reportNumMatched = false;

  // Pass 0 — the posting URL is the stable natural key. When it hits it is
  // authoritative and no heuristic runs. Tiers 1-3 below remain the fallback
  // for rows with no URL yet.
  const addUrl = normalizeUrl(addition.url);

View on GitHub (pinned to 60398d6549)

Solutions

Check batch-state.tsv and the report file for that number — if the evaluation genuinely failed, delete the orphaned TSV in batch/tracker-additions/
If the evaluation was re-run and succeeded, make sure the TSV cites the new (successful) report number
Re-run the evaluation for that offer so a real report exists, then regenerate the tracker addition from it

Example fix

# before: orphaned addition citing a failed run
batch/tracker-additions/042-acme.tsv  # report 042 = failed in batch-state.tsv

# after: remove it, re-run the evaluation, add the new TSV
rm batch/tracker-additions/042-acme.tsv
# re-run eval -> report 043 succeeds
# batch/tracker-additions/043-acme.tsv merges cleanly

Defensive patterns

Strategy: validation

Validate before calling

import { readFileSync, existsSync } from 'node:fs';
function loadFailedReportNumbers(batchStatePath) {
  if (!existsSync(batchStatePath)) return new Set();
  const failed = new Set();
  for (const line of readFileSync(batchStatePath, 'utf8').split('\n')) {
    const [num, state] = line.split('\t');
    if (state && /failed/i.test(state)) failed.add(num.trim());
  }
  return failed;
}
// Drop addition files whose report link cites a failed number BEFORE merging.

Prevention

Let the batch runner own tracker-additions files; delete orphans from failed workers instead of merging them
After a failed run, clean batch/tracker-additions/ before the retry so stale lines cannot reach the tracker
Cross-check each addition's report number against batch-state.tsv before merging by hand

When it happens

Trigger: A batch worker crashes mid-evaluation (recorded 'failed' in batch-state.tsv for report #042) but a leftover tracker-additions TSV for #042 still sits in the directory — extractReportNum() finds the number, the FAILED_REPORT_NUMBERS match fires, and the file is skipped as a possible fabricated result.

Common situations: Retried batch runs where the first attempt failed and the second succeeded under a different number; orphaned TSVs from killed workers; mixing additions directories across batch attempts.

Related errors

AI-assisted analysis of santifer/career-ops@60398d6549 (2026-08-20). Data as JSON: /api/errors/31d18be9dc63a304. Report an issue: GitHub.