Repository navigation
fix(registry): 404 garbage owners before loading GitHub profile - #262
Merged
Merged
Conversation
harlan-github-agent
Bot
added
harlan-agent-running
Contributor
Author
🤖 MERGED
GitHub merged this pull request. No material findings were recorded. 4b770da5-4088-43df-941e-e61fbb9f85c7 |
harlan-github-agent
Bot
added
harlan-agent-running
harlan-github-agent
Bot
removed
the
harlan-agent-ready
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🔗 Linked issue
Closes #260
❓ Type of change
📚 Description
Crawler-invented owner paths were costing two things on every hit: one unauthenticated GitHub users API call, and a permanent
ownersrow withsync_status='404'. The daily-checkin routine that opened #260 counted 2,941 junk rows in 24 hours (6,775 since ~2026-09-17, 9,868 owners with no repos row), and every one of them was paid for with an API call.The org profile route loaded the registry skills and the GitHub owner profile in parallel, so the 404 thrown for an empty registry still let the owner load finish its write. The registry query now runs first and the route 404s on an empty result before the owner load runs, so a path with no skills never reaches the GitHub users API or the
ownerstable. The HTTP response is unchanged; the write and the upstream call behind it are gone.A new regression test pins this: on the old ordering it fails with
githubFetchcalled forhttps://api.github.com/users/not-a-real-owner-xyz, and with the fix the same request 404s with no fetch and no owners row.One path still writes
sync_status='404': an owner with skills in the registry whose GitHub account is gone. That write doubles as the negative cache keeping repeat requests off the API for those, so I left it in place rather than moving to a storage-based cache.