fix(analytics): calculate project completion percentages - #399
Conversation
📝 WalkthroughWalkthroughAnalytics now loads all project issues and states, calculates per-project completion percentages excluding cancelled issues, and displays the results in the Active Projects list. ChangesAnalytics completion metrics
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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.
Actionable comments posted: 3
🤖 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.
Inline comments:
In `@apps/web/src/pages/AnalyticsOverviewPage.tsx`:
- Around line 99-100: Separate the workspace lookup error handling from the
derived-data requests in the effect around setWorkspace: only setWorkspace(null)
when the workspace lookup itself fails. If project, member, issue-page, or state
loading fails after setWorkspace(w) succeeds, preserve the workspace and expose
the data-load error through the existing error state or handling path.
- Around line 82-87: Update the data-loading flow around the projects fetch and
its useMemo-derived percentages so work-item mutations invalidate or refetch the
project issues and states while the page remains mounted. Ensure create, delete,
reopen, and completion events trigger the existing fetch path and cause the
displayed percentages to recalculate, rather than relying only on workspaceSlug,
issues, or states changes.
- Around line 101-103: In the request-failure path of the analytics effect,
check cancelled and return before invoking any reset setter, including
setMembers, setProjects, setIssues, and setStates. Only clear state for the
active request so stale failures cannot erase data loaded after a workspace
switch.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: df48f8a9-673d-4bf6-ae2c-b89788ebc562
📒 Files selected for processing (1)
apps/web/src/pages/AnalyticsOverviewPage.tsx
|
@dogukangoker Please take a look at coderabbit's comments |
Reviewed all three CodeRabbit comments.
Typecheck, lint, formatting and production build all pass. @martian56 |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/web/src/pages/AnalyticsOverviewPage.tsx (1)
27-43: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winStop stale pagination after cleanup.
If a workspace switch occurs after these requests start, each old
fetchAllProjectIssuescall continues to request pages until completion. The cleanup flag only prevents later state writes. Stop future page requests when cleanup runs. UseAbortSignalfor the active request if the API client supports it.Proposed minimal cancellation propagation
async function fetchAllProjectIssues( workspaceSlug: string, projectId: string, + isCancelled: () => boolean, ): Promise<IssueApiResponse[]> { const issues: IssueApiResponse[] = []; let offset = 0; - while (true) { + while (!isCancelled()) { const page = await issueService.list(workspaceSlug, projectId, { limit: ISSUE_PAGE_SIZE, offset, }); + if (isCancelled()) return issues; issues.push(...page); if (page.length < ISSUE_PAGE_SIZE) return issues; offset += page.length; } + return issues; } - Promise.all(projs.map((p) => fetchAllProjectIssues(workspaceSlug, p.id))), + Promise.all( + projs.map((p) => + fetchAllProjectIssues(workspaceSlug, p.id, () => cancelled), + ), + ),Also applies to: 90-95
🤖 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 `@apps/web/src/pages/AnalyticsOverviewPage.tsx` around lines 27 - 43, Update fetchAllProjectIssues to accept an AbortSignal and check it before each paginated issueService.list request, stopping immediately when the signal is aborted. Propagate the signal from the cleanup-aware caller so workspace switches cancel active requests when supported by the API client, while preserving existing pagination and state-write guards.
🤖 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 `@apps/web/src/pages/AnalyticsOverviewPage.tsx`:
- Around line 27-43: Update fetchAllProjectIssues to accept an AbortSignal and
check it before each paginated issueService.list request, stopping immediately
when the signal is aborted. Propagate the signal from the cleanup-aware caller
so workspace switches cancel active requests when supported by the API client,
while preserving existing pagination and state-write guards.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: fa0cedc9-0a66-40f1-a37f-a5577f2fc53a
📒 Files selected for processing (1)
apps/web/src/pages/AnalyticsOverviewPage.tsx
|
@dogukangoker Thank you for your contribution) |
2 participants
What was broken
Project completion percentages in the Analytics Overview active-project list were always displayed as 0%, regardless of completed work items.
Linked issues
Fixes #398
Root cause
AnalyticsOverviewPage.tsxrendered a hardcoded0%badge and did not load project workflow states needed to determine which work items belonged to thecompletedstate group. Additionally, the page requested issues withlimit: 200, while the API accepts a maximum limit of 100 and falls back to 50 when the supplied limit is invalid. This could produce incomplete work-item totals and inaccurate completion ratios for larger projects.The fix
limit: 100andoffsetpagination.project_id.state_id.cancelledandcanceledwork items from both the numerator and denominator.Backend aggregation, polling, and real-time subscriptions were deliberately left out of scope to keep the change aligned with the frontend-only approach agreed upon in the issue.
Why this fix is correct
The calculation uses each project's complete work-item collection rather than a truncated first page. State IDs are resolved against the loaded project states, and only work items in the
completedstate group contribute to the numerator. Backlog, unstarted, and started work items remain part of the denominator because project completion is calculated against the total actionable work-item pool. Cancelled work items do not affect either side of the ratio. Projects with no applicable work items use a 0% fallback, preventing division-by-zero errors or invalid values. The change is isolated to the Analytics Overview page and does not alter shared API contracts or backend behavior.Reproduction
maindisplays 0% for the project regardless of the completed work items.Test plan
npm run validategreenmainand passes on this branchapps/webdoes not currently provide a page-level test runner. Covered through manual regression testing and theexisting validation suite.
Regression risk
The page now performs one workflow-state request per project and additional issue requests for projects containing more than 100 work items. This can increase Analytics Overview loading time in workspaces containing many large projects. The additional requests are limited to the Analytics Overview route. Existing project, work-item, and analytics API contracts are unchanged. Manual verification covered status changes, creation, deletion, cancelled work items, backlog work items, empty projects, multiple projects, and paginated issue loading.
Screenshots / logs (if applicable)
Not included; this change updates the displayed percentage values without changing the page layout.
AI assistance
____— and AI-assisted commits include aCo-Authored-By:trailerChecklist
fix(<scope>): …and ≤ 100 chars--no-verifybypassSummary by CodeRabbit
New Features
Bug Fixes