fix(daemon): cache git info to avoid cc statusline timeout #204
Conversation
The git branch was always showing "-" because GetGitInfo() calls worktree.Status() which can take 100ms+ on large repos, exceeding the 50ms client timeout. Added git info caching with 20s TTL to CCInfoTimerService. After the first request caches the git info, subsequent requests return instantly. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Summary of ChangesHello @AnnatarHe, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a performance bottleneck in the daemon where fetching Git information could lead to client timeouts, resulting in incomplete statusline displays. By implementing a caching mechanism for Git data with a short Time-To-Live, the system can now quickly retrieve repository details, ensuring a responsive user experience and accurate status reporting without repeatedly executing expensive Git operations. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces caching for git information to resolve a timeout issue in the cc statusline. The approach is sound and correctly identifies the performance bottleneck in GetGitInfo(). The implementation adds a new caching layer with a 20-second TTL within CCInfoTimerService. My main feedback concerns a potential concurrency issue in the cache-fetching logic that could lead to a 'thundering herd' problem under specific conditions, potentially negating the fix for concurrent requests.
| func (s *CCInfoTimerService) GetCachedGitInfo(workingDir string) GitInfo { | ||
| if workingDir == "" { | ||
| return GitInfo{} | ||
| } | ||
|
|
||
| s.gitCacheMu.RLock() | ||
| cached, exists := s.gitCache[workingDir] | ||
| s.gitCacheMu.RUnlock() | ||
|
|
||
| if exists && time.Since(cached.fetchedAt) < GitInfoCacheTTL { | ||
| return cached.info | ||
| } | ||
|
|
||
| // Fetch fresh (this is the slow part) | ||
| info := GetGitInfo(workingDir) | ||
|
|
||
| s.gitCacheMu.Lock() | ||
| s.gitCache[workingDir] = cachedGitInfo{info: info, fetchedAt: time.Now()} | ||
| s.gitCacheMu.Unlock() | ||
|
|
||
| return info | ||
| } |
There was a problem hiding this comment.
There's a potential 'thundering herd' issue here. If multiple concurrent requests for the same workingDir occur when the cache is stale, all of them will execute GetGitInfo(workingDir) simultaneously. Since this is a slow operation, this could lead to all those concurrent requests timing out, which is the problem this PR is trying to solve.
Consider using a mechanism like golang.org/x/sync/singleflight to ensure only one goroutine fetches the data for a given key, while others wait for the result. This would make the caching more robust under concurrent load.
The previous on-demand caching still had cold-cache issues where the first request could timeout. This refactors to fetch git info in the background timer (every 3s) like cost data, ensuring: - First request returns immediately (may be empty briefly) - Timer fetches git info async, no timeout risk - Consistent architecture with cost data fetching - Simpler code with single active directory tracking 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Summary
GetGitInfo()callsworktree.Status()which can take 100ms+ on large repos, exceeding the 50ms client timeoutCCInfoTimerServiceTest plan
nc -U /tmp/shelltime.sock- git branch and dirty status returned correctly🤖 Generated with Claude Code