Repository navigation
fix(registry): cache org profile endpoint behind SWR read-through - #188
Merged
Merged
Conversation
harlan-github-agent
Bot
added
harlan-agent-running
Contributor
Author
🤖 MERGED
GitHub merged this pull request. No material findings were recorded. 0933ab7c-1e84-4777-8a2c-a0398171988b |
harlan-github-agent
Bot
added
harlan-agent-pending
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
1 participant
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 #183
❓ Type of change
📚 Description
The org profile route was the last bare handler on the registry API. Every crawler hit ran the full compute: the skills query, the owners read, repo source identities, generated tags, the sync summary, plus a live ungh.cc fetch per repo. That is the shape the ops ledger blames for the recurring D1 overload bursts (SKILLD-1M, SKILLD-1N and the 2026-08-05 orgs family).
The skill detail route already got the identical read-through stale-while-revalidate shield after SKILLD-1V. This gives the owner route the same treatment, one key per owner: fresh for 60s, stale served for 5min while one background refresh recomputes, and concurrent cold misses sharing a single computation. Failures stay uncached, so a 404 for an owner with no skills still recomputes per hit.
Unsure about one thing: I could not measure real hit rate. If crawler traffic concentrates on distinct cold owners, a 60s fresh window may be too short to move D1 load, and a longer TTL would trade profile freshness for fewer computes. The test also keeps the shared D1 harness honest about batches:
querySkillsbatches three SELECTs and reads.resultsoff each, which the harness'sbatch()silently dropped before.