Refresh upstream before git status and tune query polling intervals#67
Refresh upstream before git status and tune query polling intervals#67juliusmarminge merged 1 commit intomainfrom
Conversation
- Fetch tracked upstream (throttled + timeout) before `statusDetails` so ahead/behind reflects remote updates - Add integration coverage for behind-count updates after remote commits - Configure React Query stale/refetch intervals for git status and branch lists
WalkthroughThe changes introduce background upstream refresh handling in the Git service to keep status details current. A new test validates that Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Comment |
Refresh upstream before computing ahead/behind in
|
Greptile SummaryImplements throttled upstream refresh for git status to ensure
Confidence Score: 5/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant Client as React Query (Web)
participant WS as WebSocket Server
participant Git as GitCoreService
participant Remote as Git Remote
Note over Client: Every 15s refetch interval
Client->>WS: git.status({ cwd })
WS->>Git: statusDetails(cwd)
Git->>Git: Check lastUpstreamRefreshAt cache
alt Cache stale (>15s)
Git->>Git: Update cache timestamp (prevent spikes)
Git->>Remote: fetch upstream (5s timeout)
Note over Git,Remote: fetchUpstreamRefForStatus()
Remote-->>Git: Updated refs
else Cache fresh (<15s)
Note over Git: Skip fetch, use cached upstream
end
Git->>Git: Parse status --porcelain=2
Git-->>WS: { behindCount, aheadCount, ... }
WS-->>Client: Status with fresh behindCount
Note over Client: Alternative: checkout flow
Client->>WS: git.checkout({ branch })
WS->>Git: checkoutBranch(input)
Git->>Git: Perform checkout
Git->>Remote: refreshCheckedOutBranchUpstream()
Note over Git,Remote: Background fetch, no throttle
Last reviewed commit: 1595909 |
Refresh upstream before computing ahead/behind in
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/server/src/git.ts (1)
221-221: Consider bounded cache to prevent unbounded memory growth.The
lastUpstreamRefreshAtmap grows unbounded as users work across different repositories and branches. In a long-running server scenario, this could accumulate stale entries over time.This is low-priority since the memory overhead per entry is minimal (string key + number value), but worth noting for future consideration.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/server/src/git.ts` at line 221, The Map field lastUpstreamRefreshAt can grow unbounded; change it to a bounded cache or add pruning: replace the raw Map<string, number> with a capped LRU/size-limited cache (or wrap it to evict oldest entries when a max size is exceeded) or implement periodic TTL-based cleanup that removes entries older than a configured threshold; update usages of lastUpstreamRefreshAt in this class (look for reads/writes to lastUpstreamRefreshAt) to use the new cache API so the server won't accumulate stale repo/branch keys indefinitely.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/server/src/git.ts`:
- Line 221: The Map field lastUpstreamRefreshAt can grow unbounded; change it to
a bounded cache or add pruning: replace the raw Map<string, number> with a
capped LRU/size-limited cache (or wrap it to evict oldest entries when a max
size is exceeded) or implement periodic TTL-based cleanup that removes entries
older than a configured threshold; update usages of lastUpstreamRefreshAt in
this class (look for reads/writes to lastUpstreamRefreshAt) to use the new cache
API so the server won't accumulate stale repo/branch keys indefinitely.
1 participant
Summary
statusDetailssobehindCountreflects remote updates.behindCountupdates after a remote commit.Testing
apps/server/src/git.test.ts(refreshes upstream before statusDetails so behind count reflects remote updates).Note
Medium Risk
Introduces additional
git fetchcalls during status polling (albeit throttled/timeout-limited), which could affect responsiveness or network load and has behavior implications for branch status accuracy.Overview
GitCoreService.statusDetails()now proactively fetches the current branch’s upstream (with a 15s throttle and 5s timeout) sobehindCountreflects remote updates, and refactors upstream parsing/fetching into reusable helpers shared with the checkout background refresh.Adds an integration test covering the stale-remote
behindCountscenario, and tunes the web React Query configuration to use explicitstaleTimeplus periodic/background refetch intervals for git status (15s) and branches (60s).Written by Cursor Bugbot for commit 1595909. This will update automatically on new commits. Configure here.
Summary by CodeRabbit
Release Notes