4 of 6 standards met
Summary Add in-memory TTL cache for GitHub API responses (PR summaries 5min, comments 10min, merge state 2min) โ expected ~60-70% reduction in API calls Deduplicate concurrent in-flight requests Add field to CombinedPRQuery GraphQL for monitoring, with low-rate warnings Fix comment bleed when switching PRs in review mode (reset stale state on diffId change) Invalidate comment cache after mutations (reply, add, edit, resolve, unresolve) User-triggered refresh bypasses cache Test Plan [x] 11 new GitHubCache unit tests (TTL, stale-while-revalidate, invalidation, prefix invalidation) [x] All 446 ISL tests pass [x] All isl-server tests pass (pre-existing TS type errors unchanged) [ ] Manual: Open ISL, observe PR summaries load, wait 2+ min, verify no redundant API call [ ] Manual: Click refresh, verify API call happens (force refresh bypasses cache) [ ] Manual: Open review mode for PR, switch to different PR, verify no comment bleed [ ] Manual: Add/edit comment, verify fresh data after refresh [ ] Manual: Check server logs for rate limit info ๐ค Generated with Claude Code
Repository: facebook/sapling. Description: A Scalable, User-Friendly Source Control System. Stars: 6749, Forks: 347. Primary language: Rust. Languages: Rust (46.4%), Python (18.1%), Raku (9.7%), C++ (9.4%), TypeScript (9.1%). License: GPL-2.0. Homepage: https://sapling-scm.com Latest release: 0.2.20250521-115337+25ed6ac4 (9mo ago). Open PRs: 73, open issues: 235. Last activity: 1h ago. Community health: 75%. Top contributors: quark-zju, DurhamG, marmoute, muirdm, markbt, durin42, StanislavGlebik, xavierd, evangrayk, yuja and others.
Last 12 weeks ยท 1416 commits
Would people be favorable to a PR strategy where each PR's base is the head of the previous PR? So instead of You have pr1 -> master pr2 -> pr1 pr3 -> p2 pr4 -> p3 This presents a few benefits over the current strategy of overlapping PRs: PRs can be merged on GitHub (you still wouldn't want to merge out of order, and draft status PRs would help manage this) As you merge previous PRs and delete their branches, GitHub automatically updates the base of the next PR to the branch the previous PR was merged into (so after you merge pr1, GitHub will magically make your PRs pr2 -> master, pr3 -> pr2, pr4 -> p3) The changes of each commit can be reviewed in isolation on GitHub. The work on ReviewStack is admirable, but it doesn't feel as mature as the Sapling CLI and hasn't reached parity with GitHub PRs regarding features or experience.