fix(queue): isolate per-repo failures in generateSignalSnapshots

[andriypolanski]

Summary

• Closes queue: generateSignalSnapshots has no per-repo failure isolation, unlike its job-dispatch.ts sibling (#8355) #9293
• Switches generateSignalSnapshots from a bare sequential for loop to Promise.allSettled over per-repo work so one repo's data-gathering or persist failure no longer silently skips every subsequent repo in the same multi-repo invocation.
• Matches the #8355 backfill-registered-repos pattern: attempt every repo once, log a structured generate_signal_snapshots_repo_failed error per failure, then throw one aggregate error listing the failed repo full names.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves (e.g. Closes #123) — a linked open issue is required for every contributor PR.

Validation

• git diff --check
• npx vitest run test/unit/queue-trends.test.ts — 10 passed
• Scoped diff-cover vs origin/main on src/queue/signal-snapshot.ts — 100% patch lines (32/32)
• npm run actionlint
• npm run typecheck
• npm run test:coverage
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

Focused queue isolation fix; targeted queue-trends coverage includes the multi-repo partial-failure regression. Full test:ci left for CI.

Safety

• If my change touches auth, CORS, CSRF, cookies, sessions, webhooks, or repo/path access: I added negative-path tests for unauthenticated, cross-repo/unauthorized, and browser-origin requests where applicable.
• No secrets, wallets, hotkeys, trust scores, or reward values.
• Does not touch site/, CNAME, **/lovable/**, or root CHANGELOG.md.

UI Evidence

N/A — backend queue orchestration only; no visible UI change.

Notes for reviewers / gate

• Does not change fanOutRepoSignalSnapshotJobs or the per-repo queue-job fan-out path.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.35%. Comparing base (ffdea0c) to head (0e63a3a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9363      +/-   ##
==========================================
- Coverage   75.38%   75.35%   -0.04%     
==========================================
  Files         275      276       +1     
  Lines       58023    58043      +20     
  Branches     6181     6182       +1     
==========================================
- Hits        43739    43736       -3     
- Misses      14014    14037      +23     
  Partials      270      270              

Flag	Coverage Δ
backend	100.00% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/queue/signal-snapshot.ts	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-27 15:22:15 UTC}

3 files · 1 AI reviewer · no blockers · readiness 98/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR correctly refactors `generateSignalSnapshots` from a sequential for-loop into `Promise.allSettled` fan-out over an extracted `generateSignalSnapshotForRepo` helper, so one repo's data-gathering or persist failure no longer aborts processing of subsequent repos in the same invocation — it logs a structured error per failure and rethrows a single aggregate error listing failed repo names, matching the `#8355` backfill pattern. The refactor is a mechanical extraction of the loop body into a per-repo async function with no logic changes to signal-building or persistence, and the new `queue-trends.test.ts` test directly exercises the multi-repo partial-failure regression (one repo fails, sibling still persists, aggregate error thrown, structured log emitted) which is the core claim of the PR. The `selfhost-pg-retention.test.ts` changes are comment/regex updates unrelated to this PR's stated scope (they reference `#9083` PK-based retention pruning), which is scope creep beyond what's described.

Nits — 5 non-blocking

• src/queue/signal-snapshot.ts:78 uses `console.error` with `JSON.stringify` for structured logging — verify this matches the logging convention used elsewhere in the codebase (e.g. `fix(queue): backfill-registered-repos cron fan-out has no per-repo isolation, risking duplicate dispatch on partial failure #8355`'s backfill-registered-repos pattern) rather than a project-wide structured logger, if one exists.
• The `selfhost-pg-retention.test.ts` diff (regex/comment changes referencing `orb(db): 3.4 GB in one month — no retention target has a usable index, and four caches have no delete path at all #9083`) is unrelated to this PR's stated `queue: generateSignalSnapshots has no per-repo failure isolation, unlike its job-dispatch.ts sibling (#8355) #9293` queue-isolation scope and should probably be a separate PR or explained in the description.
• test/unit/queue-trends.test.ts's new test only exercises a single-failure-among-two-repos scenario; consider also covering the all-repos-fail path to confirm the aggregate error message and count are correct at the boundary.
• Confirm PR description's checked `test:ci`/`typecheck`/`audit` boxes are actually run before merge, since they're marked unchecked in the PR body.
• Consider extracting the repeated `persistSignalSnapshot` calls into a small loop over `{signalType, payload}` pairs to reduce duplication in `generateSignalSnapshotForRepo`, though this is optional style cleanup.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#9293
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 174 registered-repo PR(s), 113 merged, 22 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	andriypolanski; Gittensor profile; 174 PR(s), 22 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Linked issue satisfaction

Addressed
The diff replaces the sequential per-repo for-loop with Promise.allSettled over an extracted generateSignalSnapshotForRepo helper, collects failing repo names, logs the exact structured generate_signal_snapshots_repo_failed error, and throws a single aggregate error listing failures, matching the #8355 precedent; a new multi-repo test asserts the surviving repo's snapshot persists while the failin

Review context

• Author: andriypolanski
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Rust, Cuda, JavaScript, Kotlin, MDX, Scala
• Official Gittensor activity: 174 PR(s), 22 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Decision record

• action: merge · clause: success
• config: 03a7f8b529a9 · pack: oss-anti-slop
• record: 4ec98edb9c92 (schema v3, head 792a3d0)

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.