The federated-graph job has not validated anything since 2026-09-02 — it cannot clone the sibling repos

[avrabe]

The federated-graph job has not validated anything since 2026-09-02

Rivet Federated Graph (advisory) fails before it validates. Step list on
current main:

Sync externals (network — clones the 7 sibling repos)   failure
Validate the federated graph                            skipped
Non-vacuity guard — resolution must actually have run   skipped

error: IO error: git clone failed: Cloning into './.rivet/repos/gale'...
fatal: could not read Username for 'https://github.com': No such device or address

The runner has no credentials for the sibling repos. Step-level history:

commit	Sync externals
d4f935c1 (v0.61.0 release)	success
50889180 (v0.62 scoping)	failure
every commit since	failure

The correlation with the scoping commit is coincidental — a commit adding YAML
artifacts cannot affect a git clone of a sibling repo. Something changed about
credentials or repo visibility around 2026-09-02.

What is right about it, and what is not

Right: it is advisory, so nothing is blocked; and it fails closed — the
non-vacuity guard is skipped rather than passing vacuously. That guard exists
because of #1012, where rivet reported "0 broken cross-refs" beside 50 link
errors because resolution had never run. The design worked.

Not right: the cross-repo trace graph has been unvalidated for every
commit since a release, and nothing surfaced that. I described this job's
failure from memory twice in the org review (#1132) and was wrong both
times — once attributing it to dangling traces-to refs my local rivet
reports, once to my own scoping commit. An advisory job that is permanently red
is indistinguishable from one that is merely noisy, and maintainers stop
reading it.

Ask

1. Credentials — the job needs a token that can clone the seven siblings.
   A check that cannot fetch its inputs is not a check.
2. Escalation — an advisory job red for N consecutive commits should
   surface somewhere, or it decays into background noise. This is the same
   endgame gap as the held dependabot PRs (Feedback wanted: needs and wishes for synth #1132): a mechanism behaving
   correctly and silently is how it stops being read.

Not urgent — nothing is blocked, and the federated graph is not load-bearing for
a release. Filed so it is tracked rather than rediscovered.

[avrabe]

Correction to the framing above: this is not a missing-permission problem. All seven siblings are PUBLIC.

pulseengine/gale   private=false      pulseengine/kiln  private=false
pulseengine/scry   private=false      pulseengine/jess  private=false
pulseengine/loom   private=false      pulseengine/spar  private=false
pulseengine/meld   private=false

An anonymous clone of a public repo needs no credentials at all. So "the runner
has no credentials" was the right observation and the wrong conclusion — the
job does not need credentials to read these repos. It is being asked for them
anyway.

What could not read Username actually means here

git only prompts for a username after the transport refuses it. For a public
repo that means GitHub returned 401/403/404 to an anonymous request, and git
fell back to interactive auth on a runner with no tty — hence
No such device or address.

Two candidate causes, and they are distinguishable:

1. GitHub rate-limiting unauthenticated traffic from a datacenter IP. This
   job runs on the self-hosted hetzner fleet (runner12). Anonymous git/API
   access from datacenter address space is throttled far more aggressively than
   from a residential or GitHub-hosted range, and a throttled response makes git
   ask for a username exactly like a private repo would. The timing fits: the
   failures begin 2026-09-02, during the heaviest CI period this repo has had
   (a release wave plus ~9 PRs, all on those runners).
2. A credential-helper / insteadOf rewrite left in the runner's git config
   intercepting https://github.com/ and demanding auth that isn't there.

Testable cheaply: git ls-remote https://github.com/pulseengine/gale on the
runner, once with -c credential.helper= and once with the job's normal
environment. If anonymous works from a laptop and fails from the runner, it is
(1).

Why the fix is the same either way, and why it belongs to temper

rivet sync should authenticate even though it does not need permission —
an authenticated request gets the higher rate limit and bypasses the anonymous
path entirely. That is a token for quota, not for access, which is an
unintuitive thing for each repo to work out on its own.

This is the same shape as the CI-capacity finding in #1132: GitHub's own
limits are the binding constraint, not our configuration. There the self-hosted
fleet sat idle while the GitHub-hosted quota queued for hours; here public repos
are unclonable from the same fleet. Both are "GitHub restricting itself", and
both are cheaper to solve once at org level than seven times per repo.

The two properties I praised still hold: the job is advisory so nothing is
blocked, and it fails closed — the non-vacuity guard is skipped rather than
passing vacuously (the #1012 lesson working). What remains true is that the
federated graph has been unvalidated since the release and nothing said so.