Repository navigation
Newly broken repositories still back live registry skills #193
Description
Activity
🤖 ISSUE TRIAGE
Harlan Agent Kit posted this automated triage. It is not Harlan's personal assessment or commitment. AI open source policy.
- Route: Needs info
- Difficulty: 2/5
- Impact: 2/5
- Reproduction: No
- Codebase review: Needed
- Summary: Claim not reproducible. syncRepo already records source_resolved = 0 for upstream-gone repos via markRepoMissing on 404/410 (layers/registry/server/utils/sync-repo.ts:702-708 and 545-576). Live prod D1 queried during triage: zero skills wit
- Next action: Pull the three repo identities archived by the 2026-09-08 daily-checkin run (identity archive shipped via closed issue 163, scripts/tools/daily-checkin-data.mjs) and re-query prod D1 for their skills.source_resolved. If all are 0, close this as a metric false positive and change newly_broken_repos_impacted_24h to count only source_resolved = 1 rows; only if any are 1, extend sync-repo.ts quarantine to the listed failure paths.
- Fix with: D1 overload 500s recur after the replayable-read retry fix #192
Agent triage by Codex, 2026-10-05. This is an agent assessment.
The original allegation does not reproduce. A production read on 2026-10-05 found zero Skills with source_resolved=1 in broken repositories. The query wrote zero rows.
markRepoMissing already sets source_resolved=0, seo_indexable=0, and trust_tier=quarantined for GitHub 404/410 responses. All ten sync-repo freshness regression tests pass.
The impacted-repository metric also counts saved Skills, watches, and collections. It does not prove the source remains resolved. Recovery and source notices are covered by #291, #390, and #391.
Closing the unsupported source-resolution allegation.
Three upstream-broken repositories still back synced skills because the sync fails before recording source_resolved = 0.
Target:
layers/registry/server/utils/sync-repo.tsVerify with:
pnpm test:run test/unit/sync-repo-correctness.test.tsEstimated to change 2 files.