santifer/career-ops · error · Error

vdab: all keyword request(s) failed

Error message

vdab: all ${keywords.length} keyword request(s) failed — ${errors[0]}

What it means

The vdab provider issues one request per configured keyword and tolerates individual failures, but if every keyword request failed (succeeded === 0) it throws this error summarizing the count and the first underlying error. A keyword returning zero results is NOT a failure — the check keys off the success count, so this error means the VDAB API (or the network path to it) is effectively unreachable for this run.

Solutions

Read errors[0] (shown in the message) to identify the root cause — 403 points at key rotation, timeouts at network, 5xx at VDAB-side outage
Check VDAB API status / retry later if it is a transient outage — this error is safe to treat as 'skip this run'
If it is a 403, verify the key re-derivation path: fetch the live bundle and confirm the new VEJ key is being extracted correctly
Test connectivity to the VDAB endpoint from the machine (curl) to rule out proxy/firewall blocking
Reduce to a single keyword in a test config to isolate whether the failure is keyword-specific or global

Example fix

null

Defensive patterns

Strategy: retry

Validate before calling

null

Type guard

null

Try / catch

try {
  const jobs = await vdabProvider.fetch(entry, ctx);
} catch (err) {
  if (err.message.startsWith('vdab: all') && err.message.includes('keyword request(s) failed')) {
    console.error(`VDAB unreachable this run (${err.message}). Skipping; will retry next scan.`);
    scheduleRetry({ backoffMs: 15 * 60 * 1000 });
    return [];
  }
  throw err;
}

Prevention

Inspect the embedded errors[0] first — 403 means key rotation, timeouts mean network, 5xx means VDAB outage
Wrap scheduled scans in per-provider try/catch so one dead board does not abort the whole run
Monitor the VEJ key re-derivation path; alert when the hardcoded key 403s and the fresh bundle also fails
Test VDAB reachability with curl from the deployment environment to catch proxy/firewall blocks early

When it happens

Trigger: All keyword requests to the VDAB API failed — e.g. the API key was rejected (403) and re-derivation from the live bundle also failed, network/DNS outage, VDAB API downtime, rate limiting on every request, or a malformed request rejected for all keywords.

Common situations: VDAB rotated their VEJ key and the re-derive path broke too; corporate proxy/firewall blocking the VDAB host; VDAB maintenance window; expired/rotted hardcoded monitor key plus a changed bundle URL.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

AI-assisted analysis of santifer/career-ops@aac998c7ed (2026-09-16). Data as JSON: /api/errors/4f6619c78fd7f48e. Report an issue: GitHub.

Appendix: source

Thrown at providers/vdab.mjs:317

          try {
            const detail = await keyedFetchJson(`${DETAIL_API}${encodeURIComponent(job.id)}?preview=false`, {
              method: 'GET',
              headers: { accept: 'application/json' },
            });
            const description = extractDescription(detail);
            if (description) job.description = description;
          } catch {
            // Detail fetch is an enrichment only. Keep the listing result.
          }
        }));
      }
    }

    // Total outage = every keyword request failed. A keyword that answered with
    // zero results is not an outage, so key off the success count, not the
    // deduped result size — otherwise a legitimately-empty search throws.
    if (succeeded === 0 && errors.length) {
      throw new Error(`vdab: all ${keywords.length} keyword request(s) failed — ${errors[0]}`);
    }

    return [...byId.values()].map(({ id, ...job }) => job);
  },
};

View on GitHub (pinned to aac998c7ed)