fix(ui): implement async background analysis and thread-safe progress tracking #267#457
fix(ui): implement async background analysis and thread-safe progress tracking #267#457Shubham-Gotawade wants to merge 1 commit into
Conversation
…h thread-safe progress tracking agnivo988#267
📝 WalkthroughWalkthroughThis PR adds fine-grained, thread-safe progress tracking throughout the repository analysis pipeline to address UI freezes during large repository analysis. ProgressTracker now uses RWMutex for concurrent-safe stage reads/writes, is initialized at analysis start points, and advances explicitly at each major stage boundary (metadata, commits, contributors, languages, metrics, dependencies, vulnerabilities, hotspots, report generation). Cached and quick-mode analyses fast-forward remaining stages to keep progress feedback consistent. ChangesProgress Tracking with Thread-Safety for Repository Analysis
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
internal/ui/app.go (1)
1053-1056: 💤 Low valueFast-forward count doesn't account for already-advanced stages.
At this point, 3 stages have already been advanced (metadata, commits, contributors). The loop advances 10 more times, but only 7 are needed to reach completion. While this works due to the guard in
NextStage, it's inconsistent with the cached-result fast-forward at line 971 which correctly advances from stage 0.Consider computing the remaining stages dynamically or using a helper method like
CompleteAllStages()to avoid hardcoded counts that could drift.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/ui/app.go` around lines 1053 - 1056, The fast-forward loop unconditionally calls tracker.NextStage() 10 times even though some stages were already advanced (e.g., metadata/commits/contributors), causing a hardcoded count that can drift; update this to compute remaining stages dynamically or add a helper like tracker.CompleteAllStages() that repeatedly calls NextStage() until completion (use the tracker and NextStage symbols to locate the logic) so the code advances only the needed number of stages rather than a fixed 10 iterations.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@internal/ui/app.go`:
- Around line 1053-1056: The fast-forward loop unconditionally calls
tracker.NextStage() 10 times even though some stages were already advanced
(e.g., metadata/commits/contributors), causing a hardcoded count that can drift;
update this to compute remaining stages dynamically or add a helper like
tracker.CompleteAllStages() that repeatedly calls NextStage() until completion
(use the tracker and NextStage symbols to locate the logic) so the code advances
only the needed number of stages rather than a fixed 10 iterations.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8f8fd3c1-fee6-4541-b3eb-36ff34352647
📒 Files selected for processing (2)
internal/ui/app.gointernal/ui/progress.go
1 participant
Contributed as part of GSSoC '26.
Problem Description
When executing long-running repository analysis tasks on massive repositories or monorepos, the intensive operations blocked the primary UI execution thread. This architectural bottleneck prevented the user interface from processing frame repaints, leading to complete UI lockups, missing execution progress metrics, and broken user feedback. Fixes #267.
Solution Implemented
sync.RWMutexinsideinternal/ui/progress.go. Re-engineered tracking accessors (NextStage,GetCurrentStage, etc.) to run thread-safe, and modifiedGetAllStagesto return isolated deep-copy slices, completely eliminating data races during UI iteration passes.internal/ui/app.goby wrappinganalyzeRepoandcompareReposexecutions into standard background Go routines handled natively via Bubble Tea's asynchronoustea.Cmdsystem.TickProgressCmd) inside the UI loop to continuously trigger non-blocking model redraws, pulling metric snapshots cleanly from the protected tracker state.Verification & Test Logs
go build ./...: PASSED (Zero type or layout exceptions)Summary by CodeRabbit