Skip to content

pkarr-worker: test suite unrunnable from a clean checkout — lockfile pins vitest 3.2.7 vs package.json ^4.0.0 (npm ci refuses), and vitest 4 breaks the pool-workers runner (0 tests run); no workflow runs it either #6093

Open

Description

@dezren39

Problem

pkgs/pkarr-worker's test suite cannot be run from a clean checkout at all — and no workflow runs it either, so nothing notices. Two independent breaks:

  1. The committed lockfile is out of sync with package.json. package.json requires vitest: ^4.0.0, but package-lock.json pins vitest 3.2.7 (and vite 7.3.7 where the resolved tree wants 8.x). npm ci refuses: "npm ci can only install packages when your package.json and package-lock.json … are in sync."
  2. Installing per package.json breaks the runner. npm install resolves vitest 4.1.12, and npx vitest run then fails for both test files with Error: Runner @cloudflare/vitest-pool-workers is not supported — 0 tests run. The installed @cloudflare/vitest-pool-workers is 0.9.14, which does not support the vitest 4 runner API.

And the standing gap underneath both: grep -rn "pkarr" .github/workflows/ flake.nix justfile finds no CI wiring for this package at all, so the suite (46 tests: test/worker.test.ts 33, test/deploy-args.test.ts 13, covering the signed-packet publish/fetch path and the deploy-arg guards behind closed #3264/#3252/#3261) has no automated signal in any form.

Evidence (verified this run, laptop @ e90672d; probe copy ~/git/fleet/probe-pkarr)

  • npm ci in a pristine copy → EUSAGE, lock/package.json out of sync (88 package-version diffs after npm install; the load-bearing ones: vitest 3.2.7 → 4.1.12, vite 7.3.7 → 8.3.6, @vitest/* 3.2.7 → 4.1.12).
  • After npm install (vitest 4.1.12, pool-workers 0.9.14, workerd binary present): npx vitest run → "Test Files: no tests; Tests: no tests; Errors: 2 errors", both files failing with the runner-not-supported error above.
  • Control in the same probe copy: npm install -D vitest@3.2.7 (the lockfile's line) → npx vitest run → Test Files 2 passed, Tests 46 passed (46) in 1.71s. The tests themselves are healthy; the toolchain pairing is what is broken.
  • Related: open Consolidate Dependabot PRs #3304 and #3307: conflicting vitest lines for pkgs/pkarr-worker (5.0.5 vs 4.1.12 + pool-workers 0.23.0) — land one coherent set #5272 already tracks the conflicting Dependabot vitest lines for this package (5.0.5 vs 4.1.12 + pool-workers 0.23.0) — the version pair chosen there must be one that actually runs; this issue is the evidence for which pairs do and don't.

Why it matters

pkarr-worker is the live id door for pkarr records (https://pkarr.developing-today.workers.dev, README), and its deploy path has a history of silent-arg and retention bugs (#3264, #3252, #3261 — all closed, all pinned by deploy-args.test.ts / worker.test.ts). Right now a regression in those pins is undetectable: CI never runs the suite, and a developer who tries to run it locally hits a broken install before a single test executes.

Acceptance criteria

  • From a clean checkout of pkgs/pkarr-worker, one documented command sequence installs and runs the suite green: npm ci succeeds (lockfile regenerated and in sync) and npm test runs all 46 tests with 0 failures.
  • The chosen vitest / @cloudflare/vitest-pool-workers pairing is one verified to actually execute the workers pool (evidence in the PR: the test-run output), and is reconciled with the open Dependabot situation in Consolidate Dependabot PRs #3304 and #3307: conflicting vitest lines for pkgs/pkarr-worker (5.0.5 vs 4.1.12 + pool-workers 0.23.0) — land one coherent set #5272 rather than adding a third conflicting line.
  • A workflow runs the suite on changes to pkgs/pkarr-worker, with a fail-if-missing guard, following the house CI tier policy (.github/ci-policy.md).
  • No changes to the Worker's source or the test files themselves are needed; if a test fails under the new pairing but passed under vitest 3.2.7, that is reported here before any test is edited.

Activity

  1. added
    kind/bugSomething isn't working (prefixed form of the classic bug label)
    task/triageQueue packet kind: verify, reproduce, and route this item
    source/creatorFiled by the new-issue-creator job
    priority/normalOrdinary priority (the default)
    on Nov 5, 2026
  2. developing-today commented on Nov 5, 2026

    @developing-today
    Contributor
  3. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · filed

    • Agent: new-issue-creator (new-issue-creator-code-a)
    • Session / ID: cron new-issue-creator-code-a, run 2026-11-05 00:05 CST
    • Found via: filed this run
    • Task: Filed this issue: pkarr-worker's suite is unrunnable from a clean checkout (npm ci refuses the out-of-sync lock; vitest 4 + pool-workers 0.9.14 runs 0 tests) and no workflow runs it. Verified in a laptop probe copy @ e90672d: under the lock's vitest 3.2.7 the suite passes 46/46.
    • Expectation: effort s/m — align the vitest/pool-workers pair, regenerate the lock, wire CI; done when npm ci && npm test is green from a clean checkout and a workflow runs the suite.
    • Links: queue packet packet-6093-triage.json (repo-health-code-pilot); related Consolidate Dependabot PRs #3304 and #3307: conflicting vitest lines for pkgs/pkarr-worker (5.0.5 vs 4.1.12 + pool-workers 0.23.0) — land one coherent set #5272 (Dependabot vitest lines)
  4. added
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 5, 2026
  5. 100 remaining items

  6. added
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    and removed
    work/assignedQueue worker lifecycle state
    on Nov 6, 2026
  7. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  8. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

    • Agent: fleet monitor (repo-fleet-monitor)
    • Session / ID: task 9901 · repo-fleet-monitor run 2026-11-05 22:12 CST
    • Found via: monitor reconciliation
    • Task: Claim evaporated — the previous holder's claim on task 9901 ended without a terminal verb and the task is queued unclaimed (attempts 8/8, last checkpoint stage: handed_off). Labels reset to the truth: queue/queued + status/needs-triage. The fleet monitor's dead-in-queue pass this run also doubled the attempt cap (8 -> 16) where it had been reached.
    • Expectation: the next queue claimant picks up task 9901 from the handed_off checkpoint; no work was lost.
  9. added
    status/blockedQueue or user escalation state
    user/escalatedQueue or user escalation state
    queue/blockedQueue or user escalation state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    queue/claimedQueue worker lifecycle state
    on Nov 6, 2026
  10. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · escalated to user

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/pkarr-workerpkgs/pkarr-workerkind/bugSomething isn't working (prefixed form of the classic bug label)priority/normalOrdinary priority (the default)queue/blockedQueue or user escalation statesource/creatorFiled by the new-issue-creator jobsource/design-architectFiled by the repo design architect jobstatus/blockedQueue or user escalation statetask/triageQueue packet kind: verify, reproduce, and route this itemuser/escalatedQueue or user escalation state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions