🤖 SPARQ agent — robustness finding, not a defect in any one PR.
What. The Dump cargo metadata (default features, no build) step in the quick-gates job of .github/workflows/vectorized-feature-off.yml (feeds Leg 1, check-vectorized-feature-off.py --leg1) runs a bare cargo metadata --format-version 1 with no retry and no Swatinem/rust-cache step.
Why it matters. crates/sparq-lws-core/Cargo.toml:230 declares a git dependency (solid-oidc-verifier = { git = "https://github.com/jeswr/solid-oidc-verifier", rev = 89c8962... }). cargo metadata must therefore check out that git source before it can resolve — verified directly: with --offline the command fails with can't checkout from 'https://github.com/jeswr/solid-oidc-verifier': you are in the offline mode. So Leg 1 cannot run without a successful network fetch of a third-party git remote.
The quick-gates job name contains no advisory/informational token, so per the workflow header comment the ci-summary aggregator treats it as a required check. A transient fetch failure or rate-limit on that git remote therefore reds a required gate on a PR unrelated to the vectorized feature.
The same exposure applies to the preceding rustup default stable / rustup show active-toolchain step, which materialises the rust-toolchain.toml pin (1.97.1) and downloads it whenever the runner image lags.
Suggested fix (not applied here — out of scope). Add a retry (or a Swatinem/rust-cache restore keyed on Cargo.lock) around the cargo metadata step so one transient remote failure does not red the gate. Optionally vendor/mirror the solid-oidc-verifier rev.
Scope honesty. I did NOT confirm this reddened any specific run — I have no CI log access from this tree. Leg 1, Leg 3 and the tripwire --self-test all reproduced GREEN locally on the PR head, so the gate's substantive content is passing; this is about the step's fragility, not a real invariant violation.
🤖 Discovered by the SPARQ worker while implementing #2502. Out-of-scope for that PR; captured as follow-up.
What. The
Dump cargo metadata (default features, no build)step in thequick-gatesjob of.github/workflows/vectorized-feature-off.yml(feeds Leg 1,check-vectorized-feature-off.py --leg1) runs a barecargo metadata --format-version 1with no retry and noSwatinem/rust-cachestep.Why it matters.
crates/sparq-lws-core/Cargo.toml:230declares a git dependency (solid-oidc-verifier = { git = "https://github.com/jeswr/solid-oidc-verifier", rev = 89c8962... }).cargo metadatamust therefore check out that git source before it can resolve — verified directly: with--offlinethe command fails withcan't checkout from 'https://github.com/jeswr/solid-oidc-verifier': you are in the offline mode. So Leg 1 cannot run without a successful network fetch of a third-party git remote.The
quick-gatesjob name contains noadvisory/informationaltoken, so per the workflow header comment theci-summaryaggregator treats it as a required check. A transient fetch failure or rate-limit on that git remote therefore reds a required gate on a PR unrelated to the vectorized feature.The same exposure applies to the preceding
rustup default stable/rustup show active-toolchainstep, which materialises therust-toolchain.tomlpin (1.97.1) and downloads it whenever the runner image lags.Suggested fix (not applied here — out of scope). Add a retry (or a
Swatinem/rust-cacherestore keyed onCargo.lock) around thecargo metadatastep so one transient remote failure does not red the gate. Optionally vendor/mirror thesolid-oidc-verifierrev.Scope honesty. I did NOT confirm this reddened any specific run — I have no CI log access from this tree. Leg 1, Leg 3 and the tripwire
--self-testall reproduced GREEN locally on the PR head, so the gate's substantive content is passing; this is about the step's fragility, not a real invariant violation.