Repository navigation
fix(github): name an unfiltered empty project view instead of blaming a filter - #20588
Conversation
Empty query still used items(query:\$q), which routes through GitHub's Projects search index and can return totalCount 0 while the board is full during index lag. Omit the query argument when the view filter is empty. Fixes #12648.
…ters Unfiltered item fetches omit items(query:) so boards skip search-index lag. The View.filter field is still '' when GitHub returns null. Co-authored-by: Cursor <cursoragent@cursor.com>
… a filter The search-index workaround in this branch was a no-op. Live introspection of ProjectV2.items shows `query` is declared `String = ""`, so omitting the argument and sending `$q = ""` coerce to the identical resolver input; GitHub applies declared defaults for omitted args (verified against its own endpoint). There is no non-search item field on ProjectV2 and ProjectV2View has no `items` at all, so no request shape can dodge the index. Revert the branching query construction and the module it added. What the user actually reported in #12648 is the copy: a view with no filter rendered "No items match this view's filter", which reads as data loss when a freshly populated board momentarily comes back empty. Word the empty state from the view's own filter — the filter message only when there is a filter, and an honest "no items yet" plus a transience hint when there is not — and share the one implementation between the table and roadmap surfaces. Refs #12648.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (12)
Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe change adds Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to The updated empty-state messaging correctly distinguishes filtered and unfiltered project views, with no actionable merge risk identified. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 6 files. (6 skipped: 6 unsupported.) Full details: Description checkExplanation The description provides detailed rationale, implementation scope, testing results, and issue references. However, it does not follow the required template and omits required sections, including ELI5, What Changed, Linked Issue with a
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
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 |
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
The new empty-state copy can still be false: it decides from the view's authored filter, not the query the rows were actually fetched with, so a no-result search override (or Orca's repo-selection filter) on an unfiltered view now reports "This view has no items yet."
Reviewed changes
- Unfiltered empty state named from the filter —
ProjectItemsEmptyStatepicks between the existing filter-miss copy and the new "no items yet" copy onfilter.trim(). - Duplicated empty blocks folded —
ProjectViewListandProjectRoadmapnow render the shared component instead of byte-identical inline blocks. - Two i18n keys added to all six catalogs; extraction/catalog/coverage/runtime-catalog checks all pass.
- Doc correction — the
GitHubProjectView.filtercomment now reflects that GitHub's declaredString = ""default makes omitted and empty equivalent. - Tests — new
ProjectViewStates.test.tsxplus an unfiltered roadmap case.
The filtered-branch key reuse and the two new hash IDs match the repo's existing extraction scheme (verified by running verify:localization-extraction), so nothing else here looks off.
DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏
| export function ProjectItemsEmptyState({ filter }: { filter: string }): React.JSX.Element { | ||
| if (filter.trim().length > 0) { |
There was a problem hiding this comment.
filter is the view's authored filter, not the query the rows were fetched with. When the user types a no-result search in the toolbar's ProjectSearchInput, useProjectViewTable fetches with the override but table.selectedView.filter stays the authored value, so an unfiltered view renders "This view has no items yet. Recently added items can take a while to appear." for items that simply didn't match the search — the same misattribution as #12648, in the other direction.
Technical details
# Empty-state reason ignores the effective row filter
## Affected sites
- `src/renderer/src/components/github-project/ProjectViewStates.tsx:239` — predicate only inspects the authored `filter`.
- `src/main/github/project-view/project-view-table.ts:116-118` — `effectiveQuery = args.queryOverride ?? selectedView.filter`, but the returned `selectedView` (lines 114, 167) is never updated, so the override is invisible downstream.
- `src/renderer/src/components/github-project/ProjectViewToolbar.tsx:63-91` — `ProjectSearchInput` writes the ephemeral override through `setAppliedQueryByView`.
- `src/renderer/src/components/github-project/useProjectViewTable.ts:173-184` — `visibleTable` also drops rows not matching `selectedRepoIds` (`filterProjectTableRowsBySelectedRepos`), another way to reach `rows.length === 0` with `filter === ''`.
## Required outcome
- The "view has no items yet" copy should appear only when neither the view filter nor any ephemeral/local filter removed rows. A search-no-results state and a repo-selection-no-results state should read as such, not as a genuinely empty view.
## Suggested approach (optional)
- Thread the effective query (e.g. `currentAppliedOverride`) and/or a "rows dropped locally" signal from `ProjectViewWrapper`/`useProjectViewTable` into the empty state as a discriminated reason, rather than inferring it from `selectedView.filter` alone.
## Open questions for the human (optional)
- Is the repository-selection filter intended to be the reason for an empty project list, and if so does it warrant its own copy?
Replaces #13561 (external contribution by @bbingz), which targeted the same issue with a change that turns out to be a no-op.
Why #13561 could not work
#13561 removed the
query:argument fromProjectV2.items(...)for unfiltered views, on the theory that omitting it skips GitHub's Projects search index. Live introspection says otherwise:queryis declaredString = "". Per GraphQL spec §6.4.1 (CoerceArgumentValues), an omitted argument with a declared default contributes that default to the coerced argument map, so the resolver receives""either way. Confirmed empirically against GitHub's own endpoint using__Type.fields(includeDeprecated: Boolean = false): omitted and explicit-default both return 14 fields, explicit non-default returns 19. GitHub applies declared defaults server-side.Two further schema facts close the door on any client-side fix:
itemsis the only item enumeration onProjectV2— there is no non-search field to fall back to.ProjectV2Viewhas noitemsfield at all, so there is no view-scoped connection traversal either.No request shape Orca can emit avoids the index.
What this PR does instead
The real user-visible defect in #12648 is the message, not the request. A view with no filter rendered "No items match this view's filter" — factually wrong, and it reads as data loss when a freshly populated board momentarily comes back empty.
ProjectItemsEmptyStatewords the empty state from the view's own filter: the existing filter message only whenfilter.trim()is non-empty, otherwise "This view has no items yet." + "Recently added items can take a while to appear."Also folds together the byte-identical empty-state blocks that
ProjectViewList.tsxandProjectRoadmap.tsxeach carried (both reusing the same translate key), and corrects theGitHubProjectView.filterdoc comment, which asserted a query-shape rationale that does not hold.This does not make a lagging board show items — nothing client-side can. It stops Orca from misattributing the emptiness, which is what the issue reporter asked for as the fallback remedy.
Verification
pnpm tc— exit 0pnpm test(github-project, i18n, main/github) — 1002 passed / 102 filespnpm run check:code-quality:changed— 0 new findings across all five gatesoxlint— exit 0, sanity-checked against a seeded violationReferences #12648 (already closed) rather than claiming to close it.
Testing
pnpm typecheck— exit 0oxlint— exit 0 (sanity-checked against a seeded violation);pnpm run check:code-quality:changed— 0 new findings across all five gatespnpm test— 1002 passed across 102 filespackage (windows)and all 8 test shardsNotes
ProjectItemsEmptyState/ "view" / "filter" / "items" are provider-neutral names. Nothing GitHub-specific was introduced for a generic concept; the module itself is GitHub Projects v2, which has no GitLab counterpart in this codebase.itemsis the only enumeration onProjectV2. It stops Orca from misattributing the emptiness, which is what the issue reporter asked for as the fallback remedy.