fix(vitest): return early when queue batch is empty

[pbomb]

Problem

In queue mode, Knapsack Pro signals agents that the queue is exhausted by returning an empty array from the API. knapsack-pro-vitest was passing that empty array directly to startVitest('test', [], ...).

Vitest interprets an empty filter list as "no test files to run" and exits with code 1 ("No test files found, exiting with code 1"). The package's getTestResults function then reads process.exitCode !== 1 to determine isTestSuiteGreen, so every agent that receives one or more empty batches marks the entire suite as failed — even when all actual tests passed.

Fix

Return early from onSuccess with a green result when testFiles is empty. This matches the expected queue-exhausted behaviour: no files assigned to this agent = no failures.

const onSuccess: onQueueSuccessType = async (testFiles: TestFile[]) => {
+  if (testFiles.length === 0) {
+    return { recordedTestFiles: [], isTestSuiteGreen: true };
+  }
  const filters = testFiles.map((testFile) => testFile.path);
  ...

Reproduction

Observed when using KNAPSACK_PRO_TEST_FILE_LIST_SOURCE_FILE with a vitest workspace that uses projects: [...] config. On a multi-agent run, agents that receive the queue-exhausted signal log "No test files found, exiting with code 1" and the overall suite is reported as failed despite all tests passing.

Workaround currently in use: --passWithNoTests CLI flag (which makes vitest exit 0 for empty filter lists). That flag can be dropped once this fix is released.

[3v0k4]

I'm planning to review this week. Thanks 🙏

[3v0k4]

The onSuccess function is called from fetchTestsFromQueue (in core/src/knapsack-pro-core.ts) as follows:

private fetchTestsFromQueue(...) {
  this.knapsackProAPI
    .fetchTestsFromQueue(...)
    .then((response) => {
      ...
      const isQueueEmpty = queueTestFiles.length === 0;

      if (isQueueEmpty) {
        this.finishQueueMode();
        return;
      }

      onSuccess(queueTestFiles).then(

So in the normal case this should not happen. But it could a problem with Fallback Mode.

When Fallback Mode is triggered, there's another call to onSuccess a bit below what I shared above. To confirm that, would you be willing to check if in the logs for the node that failed you see anything like "Fallback Mode has started ..."?

As soon as we confirm, I'd be happy to take care of the fix.

[pbomb]

@3v0k4 This ended up not being the root cause. We were able to resolve our issue with the current release. I'm closing this PR.