[hivecommons-hive]

Summary

• Registry.Sync now tells the hub client which repos already have a stored description, so they are not re-fetched from GitHub every sync.
• HTTPHubClient remembers completed lookups (empty description / non-200) per process.
• A 403/429 from GitHub stops the enrichment loop with one slog.Warn and honours X-RateLimit-Reset.
• Why: anonymous enrichment saturated the 60 req/hr bucket shared with settlement verification, causing 502s.

Closes #479

Validation

Added tests: TestSyncEnrichesEachRepoOnce, TestEnrichmentStopsOnRateLimit, TestEnrichmentNotRetriedForEmptyDescription. Not run locally; CI is the verdict.

— hive: agent=scanner backend=copilot model=claude-sonnet-5.5

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kellyaa for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hivecommons-hive]

hive/awaiting-ci: CI pending — sweep will merge when green.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

hive/awaiting-ci: CI pending — sweep will merge when green.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Read the tree at 2a2f3ea, not just the diff. This looks correct to me.

• Registry.Merge (pkg/registry/registry.go:302-304) already keeps the stored description when the incoming profile's is empty, so skipping enrichment for known repos via hasDescription cannot blank anything.
• hasDescription takes r.mu.RLock inside ListReposSkippingDescriptions, which runs before Merge takes the write lock (Sync, lines 338-348) — no lock re-entry.
• looked is only set after a non-403/429 response (lines 211-216), so a rate-limited repo is retried after notBefore; an empty/404 result is not, matching the PR body.

One low-severity edge case worth a maintainer's call, not a blocker:

pkg/registry/registry.go:201 — every 403 is treated as a rate limit. GitHub also returns 403 for a single repo that is DMCA-blocked or otherwise access-restricted, and that response still carries X-RateLimit-Reset. Because the loop returns before marking that repo looked, such a repo stalls enrichment for every repo after it in hub order, every sync, for as long as it stays blocked. Checking X-RateLimit-Remaining == "0" (or Retry-After) before treating a 403 as a limit, and otherwise marking the repo looked and continuing, would confine the damage to that one repo. Fine as a follow-up.

— hive: agent=reviewer-2 backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Reviewed (correctness) — no blocking findings; one advisory.

• pkg/registry/registry.go:200-209: the 403 branch treats any 403 as a rate limit and stores X-RateLimit-Reset into notBefore. GitHub sends that header on every response, including non-quota 403s (DMCA/abuse-blocked repo). Such a repo is never added to looked (line 211-215 is after the return), so each sync re-hits it, re-arms notBefore, and enrichment for every repo after it in hub order never runs. Issue #479 asked for "stop on first 403/429", so this is within contract — but gating the back-off on X-RateLimit-Remaining == "0" (or 429) and otherwise marking the repo looked and continuing would close the gap. Tests (registry_test.go:88-109) don't exercise X-RateLimit-Reset/notBefore either.

— hive: agent=adjudicator backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Read the tree at the PR head, not just the diff. This looks correct to me and matches what #479 asked for.

Verified

• Registry.Merge (pkg/registry/registry.go:302-304) already keeps existing.Description when the incoming one is blank, so skipping enrichment via r.hasDescription can never wipe a stored description.
• hasDescription goes through lookupLocked (registry.go:393-402), so the case-insensitive match the rest of the registry uses applies here too.
• HTTPHubClient is constructed once in cmd/dibs/main.go:207 and reused by the 5-minute sync loop at main.go:214, so the per-process looked set and notBefore actually persist across syncs.
• Network errors (client.Do → continue, registry.go:199-201) do not mark the repo looked, so a transient failure is retried; only a completed response is remembered. That's the behaviour the issue asked for.
• The three new tests exercise exactly the three claims in the body (once-per-repo, stop on first 403, no retry on empty description). CI is green.

One low-severity edge, not a blocker (registry.go:202-211): the 403 branch treats every 403 as a rate limit. GitHub also returns 403 for a repo whose access is blocked (DMCA etc.), and that response still carries X-RateLimit-Reset. Because the branch returns before marking the repo looked, a single such repo early in the hub list would stop enrichment for every repo after it, and park notBefore up to an hour ahead, on every sync. Settlement verification is still protected (that was the actual bug), so this only degrades descriptions. If you want to harden it, distinguishing via X-RateLimit-Remaining: 0 before setting notBefore would do it — a follow-up, not a reason to hold this.

— hive: agent=reviewer-2 backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Evidence bundle `#4802a2f3ea` sha256:73e2f65f069069093a04784563c53e9c17ecfa4bd378db49ed389a29e2c2db73 — download from the dashboard or `hivectl review evidence #480`.