Repository navigation
ci: jobs fail with 'FlakeHub registration required' authentication error (clippy-lint observed on #1806, #1820) #2120
Description
Problem
CI jobs are failing with a FlakeHub authentication error that has nothing to do with the code under test:
FlakeHub registration required. Unable to authenticate to FlakeHub. Individuals must register at FlakeHub.com; Organizations must create an organization at FlakeHub.com.
Evidence (2026-10-29, two independent PRs)
- PR id(world): wire manifest apply — module install + schedules over the wire (#807) #1820, run 40810482013, job 123254382153 (
nix flake check (clippy-lint)) — failed with the FlakeHub annotation above; the run's other completed checks passed. - PR id(search): author index, author/kind terms, multi-term AND — fix #800 #1806, run 40804099293, job 123242262922 (
nix flake check (clippy-lint)) — same FlakeHub failure annotation; all 28 other checks on the PR pass (cargo-check, test-unit, all test shards, fmt, etc.).
In both cases gh run rerun --failed is refused while the workflow run still has queued jobs, so the failure cannot be cleared promptly, and queue-worker tasks for #807 and #800 are parked on it.
Impact
Any PR whose clippy-lint job hits this cannot go fully green, which blocks merge-under-green-checks for the fleet even when the change itself is verified by every other check.
Acceptance
- The cause is identified (FlakeHub cache/auth configuration in the workflow, org registration state, or a Determinate/FlakeHub change) and recorded here.
- CI no longer fails jobs with the FlakeHub authentication error — either the cache is authenticated/registered correctly, or the workflows stop depending on FlakeHub where it is not required.
- A re-run of a previously affected PR's clippy-lint job passes (or fails only on a real code finding).
Filed by the repo queue worker (lane A shift, 2026-10-29) after observing the same failure on two unrelated PRs in one shift.
Acceptance criteria
- The cause is identified (FlakeHub cache/auth configuration in the workflow, org registration state, or a Determinate/FlakeHub change) and recorded on this issue.
- CI no longer fails jobs with the FlakeHub authentication error — either the cache is authenticated/registered correctly, or the workflows stop depending on FlakeHub where it is not required.
- A re-run of a previously affected PR's clippy-lint job passes (or fails only on a real code finding).
Activity
developing-today commentedon Oct 29, 2026
CODE-1022
dezren39 commentedon Oct 29, 2026
Additional evidence (queue worker lane A, 2026-10-29 ~05:55Z): on PR #1820 run 40810482013, two more jobs have now failed with the identical FlakeHub authentication annotation —
nix flake check (cargo-fmt-check)(job 123254382184) andnix flake check (treefmt-check)(job 123254382213) — alongside the earlier clippy-lint failure. No code-level failure annotation exists on any of them; the separatetreefmt checkandcargo-check-family checks that did run passed. The failure is spreading across job types as the run drains its queue, which points at the FlakeHub cache/auth step rather than any single job's setup.dezren39 commentedon Oct 29, 2026
Intake review
source/queue-workerapplied.queue/queuedwith no queue task and enqueued triage task 3133 this run, so it is owned.🤖 Fleet monitor intake enrichment, 2026-10-29. Acceptance criteria appended to the body (original preserved verbatim above it); labels normalized.
dezren39 commentedon Oct 30, 2026
🤖 Agent note · done
Cause (from run 40804099293, job 123242262922, 2026-10-29T04:35Z)
The job's log names it directly:
id-token: writeandcontents: readare set for this step's (or job's) permissions so that GitHub Actions provides OIDC token endpoints."Verified at HEAD: all four workflows using
DeterminateSystems/magic-nix-cache-actionv15 declare onlycontents: read—id-check.yml:65,id-bench.yml:31,id-e2e-nightly.yml:21,mcpx-nixbuild.yml:35— none grantsid-token: write. So the cache action cannot OIDC-authenticate, yet still tries FlakeHub (because determinate-nixd is present) and fails the job in a setup step that has nothing to do with the code under test. It is not clippy-specific: run 40810482013 (PR #1820) failed the same way in the cargo-fmt/treefmt/clippy/rustfmt jobs on a later attempt; which jobs trip it is timing/cache-path dependent.Fix routes (in task 3761)
id-token: write— only sufficient if the developing-today organization is actually registered on FlakeHub, which the error text suggests it is not; registering an org is an admin action, not a worker PR.18 remaining items
dezren39 commentedon Oct 30, 2026
🤖 Correction (Lane D, task 3761): the timestamps in my parked note above (04:02Z / 04:04Z) were mis-stated — the CI check and park actually happened at 2026-10-30T03:44–03:46Z (park not_before 04:06Z confirms). The check counts themselves (7 SUCCESS / 31 QUEUED) are from the live PR read. — queue worker Lane D
dezren39 commentedon Oct 30, 2026
🤖 Agent note · parked (merge queued)
basic: proxy port fallbacksSUCCESS onbb6e68e6; Codex summary atbb6e68e6reports no findings and there are no unresolved review threads; PR is MERGEABLE; diff is the four workflows only. The one completed failure,basic: nix build, is not the FlakeHub error and not this diff: its cache step ran (GitHub cache throttling noted in-log) and the build failed only on the pre-existing mcpx docs tests (internal/defaultsTestEveryDocumentationLinkResolves,internal/settingsTestEveryDocumentHasAChapter — the same two packages red on main). No run of this PR shows 'Unable to authenticate to FlakeHub' — the acceptance evidence the fix works. The remaining id-check flake checks are QUEUED in the repo-wide runner backlog.gh pr merge --squashplaced PR fix(ci): disable FlakeHub in magic-nix-cache — it hard-fails jobs on auth (#2120) #2519 in the merge queue (position 1) at ~2026-10-30T04:16Z.fixed_mergedand close this issue.