Stabilize GUI project API polling#264
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
More reviews will be available in 11 minutes and 28 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (12)
📝 WalkthroughWalkthroughAdds a route-based project resolver, migrates screens and shared components to it, introduces an inbox redirect route, preserves project list identity during reconciliation, and updates daemon project listing to use cached liveness and metadata lookup. It also changes restart verification for dashboard ownership and caches the tmux session prefix. ChangesApp: useRouteProject hook, screen migration, inbox alias, and project reconciliation
Daemon: project scanner, metadata store, liveness/route caching, runtime-restart, tmux prefix
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 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 `@app/app/`(main)/(tabs)/project/index.tsx:
- Line 214: The routed project query is being dropped when section links are
rebuilt because this screen only reads project from useRouteProject(), so a
pending URL project= can be lost before the list resolves. Update the project
screen to also use the stable projectPath exposed by useRouteProject(), and make
the link-building logic preserve that path instead of reconstructing /project
from the selected project fallback. Focus on the useRouteProject() destructuring
and the section-link builder that currently rebuilds the URL.
In `@app/app/inbox.tsx`:
- Around line 5-7: The browserSearchValue() helper is using
window.location.search in a shared route, which is not safe for native
rendering. Update inbox.tsx to read project and lens from
useGlobalSearchParams() instead, then pass those values through
cleanSearchValue() so the route works consistently without relying on window.
In `@app/components/screens/AgentChatScreen.tsx`:
- Around line 72-75: The plans navigation from AgentChatScreen is only carrying
sessionId, so it can lose the route-resolved project context. Update the
push/navigation call in AgentChatScreen to forward projectPath alongside
sessionId, using the projectPath obtained from useRouteProject(), so the plans
screen stays scoped to the same project even when the stored selection differs.
In `@app/components/screens/ServiceDetailScreen.tsx`:
- Around line 49-52: `goBack()` in `ServiceDetailScreen` should use the
route-stable `projectPath` instead of `project?.path` so back navigation stays
tied to the current route. Update the navigation logic in `goBack` to read from
`useRouteProject()`’s `projectPath` (with the existing fallback behavior if
needed) and ensure the query param is preserved when the project record in
`projectsAtom` has not loaded yet.
In `@app/components/WorktreeDashboard.tsx`:
- Around line 581-585: The dashboard detail navigation handlers in
WorktreeDashboard should use the routed projectPath consistently instead of
project?.path, since the atom state is already keyed by projectPath and the
unresolved-route case can lose the project query param. Update the route changes
in the detail handlers (the ones that navigate to the next screen) to pass
projectPath from useRouteProject() so the destination stays bound to the current
routed project rather than falling back to selection.
In `@app/stores/projects.ts`:
- Around line 82-90: The reconcileProjectList() sort is not deterministic when
multiple DaemonProject entries share the same name, causing unstable ordering
and unnecessary snapshot churn. Update the sorting logic in
reconcileProjectList() to use a stable tie-breaker after name (for example, a
unique project identifier or other deterministic field available on
DaemonProject) so duplicate names always sort the same way. Keep the comparison
logic in sameProjectSnapshot() and the index-by-index reconciliation behavior
unchanged, but ensure the sorted array order is fully deterministic before
comparing previous and incoming lists.
In `@src/project-scanner.ts`:
- Around line 52-55: The tmux prefix is being computed once from the daemon’s
current cwd instead of per project, which makes `dashboardSessionName` incorrect
for repos with different local config. Update `getConfiguredTmuxSessionPrefix`
to take a project root (or repo root) and pass that through to `loadConfig()`,
then have `listDesktopProjects()` and any other callers derive the session
prefix from each `entry.repoRoot` so the published dashboard session matches the
project’s own config.
- Around line 43-49: The path check in shouldHideDesktopProject is too broad
because projectPath.startsWith(tmpDir) can match sibling directories like
/tmp-foo; update the temp-project detection to use a path-boundary-aware
comparison, such as relative path logic or a separator-aware prefix check. Keep
the existing basename and aimux- prefix behavior, but ensure only projects
actually under the hidden temp dirs are filtered.
🪄 Autofix (Beta)
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: defaults
Review profile: CHILL
Plan: Pro
Run ID: c6bfb631-45c2-4ddb-bfaf-4025ee531c67
📒 Files selected for processing (24)
app/app/(main)/(tabs)/(dashboard)/graveyard.tsxapp/app/(main)/(tabs)/(dashboard)/index.tsxapp/app/(main)/(tabs)/(dashboard)/plans/[sessionId].tsxapp/app/(main)/(tabs)/(inbox)/notifications/index.tsxapp/app/(main)/(tabs)/(threads)/threads.tsxapp/app/(main)/(tabs)/coordination/index.tsxapp/app/(main)/(tabs)/library/index.tsxapp/app/(main)/(tabs)/project/index.tsxapp/app/(main)/(tabs)/topology/index.tsxapp/app/_layout.tsxapp/app/inbox.tsxapp/components/WorktreeDashboard.tsxapp/components/screens/AgentChatScreen.tsxapp/components/screens/ServiceDetailScreen.tsxapp/lib/use-route-project.tsapp/stores/projects.test.tsapp/stores/projects.tssrc/daemon.test.tssrc/daemon.tssrc/metadata-store.tssrc/project-scanner.tssrc/runtime-restart.test.tssrc/runtime-restart.tssrc/tmux/runtime-manager.ts
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/daemon.ts (1)
723-730: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winOnly expose endpoints that match the live service.
loadMetadataEndpointByProjectId(project.id)can return a stale metadata file for an old pid whileserviceAliveis computed from the currentProjectServiceState. That can make/projectsadvertise a live/current service with an endpoint for a different or dead process. Gate the endpoint by the live service pid and null it when the service is not alive.Proposed fix
return listRegisteredDesktopProjects().map((project) => { const service = servicesById[project.id] ?? null; const serviceAlive = service ? this.isProjectServiceLive(service) : false; + const metadataEndpoint = service && serviceAlive ? loadMetadataEndpointByProjectId(project.id) : null; return { ...project, service: serviceAlive ? service : null, serviceAlive, - serviceEndpoint: loadMetadataEndpointByProjectId(project.id), + serviceEndpoint: metadataEndpoint?.pid === service?.pid ? metadataEndpoint : null, }; });🤖 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 `@src/daemon.ts` around lines 723 - 730, The `/projects` response is exposing a metadata endpoint even when it may belong to a stale or dead process; update the project mapping in `src/daemon.ts` so the `serviceEndpoint` is only returned when it matches the currently live `ProjectServiceState` for that project. Use the existing `service`, `serviceAlive`, and `loadMetadataEndpointByProjectId` logic in the same return object, and add a pid/liveness check so the endpoint is nulled whenever the live service is absent or does not match the current pid.
🤖 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.
Outside diff comments:
In `@src/daemon.ts`:
- Around line 723-730: The `/projects` response is exposing a metadata endpoint
even when it may belong to a stale or dead process; update the project mapping
in `src/daemon.ts` so the `serviceEndpoint` is only returned when it matches the
currently live `ProjectServiceState` for that project. Use the existing
`service`, `serviceAlive`, and `loadMetadataEndpointByProjectId` logic in the
same return object, and add a pid/liveness check so the endpoint is nulled
whenever the live service is absent or does not match the current pid.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 834646d2-0c0e-4fb7-a78f-9fc8a03172ff
📒 Files selected for processing (3)
app/app/inbox.tsxsrc/daemon.test.tssrc/daemon.ts
|
Independent reviewer finding triage: By design. |
|
Independent reviewer finding triage: By design for this PR. Cached true entries still call |
|
@coderabbitai review |
✅ Action performedReview finished.
|
1 participant
Summary
Verification
Summary by CodeRabbit