Repository navigation
fix: task board hides a busy project's open tasks past the 500-row limit - #197
Open
Venkateshvenki404224 wants to merge 1 commit into
Open
Venkateshvenki404224 wants to merge 1 commit into
Venkateshvenki404224 wants to merge 1 commit into
Conversation
A project with 119 open tasks rendered as a completely empty board: Someday, Backlog, To Do and In Progress all showed zero while Done showed hundreds. TasksPage ran one unscoped query -- every non-archived task, `due_date asc`, limit 500 -- and `filtered` then narrowed those rows client-side. A filter cannot recover a row the server never sent, so the project chip could only ever reveal what happened to land in those 500 rows. With 1,013 tasks on the site and 918 of them in one project, the window filled with that project's completed work. Of the 500 rows reaching the browser, 427 were Moltbook and every one was Done; the 513 rows cut at the boundary included 118 To Do, 1 In Progress and 4 Blocked. No UI action could bring them back. `due_date asc` made it worse by being an arbitrary order here: no task on the site has a due date, so the tie-break decided which rows survived truncation. Changes: - TasksPage sends `project` to the server when a project is selected, so the row budget is spent on rows that can actually be shown. Status, priority and assignee stay client-side, keeping those toggles instant. - Order by `due_date asc, modified desc` in both list views, so a truncated window keeps recently-touched work instead of an arbitrary slice. - Raise the limits 500 -> 2000. ProjectDetailPage was already project-scoped but still truncated a 918-task project. - ProjectsTab (dashboard) derives per-project counts from its rows, so the short window was not just hiding tasks, it was reporting wrong totals on every card. Same limit raise plus an explicit stable order. Verified against the live site through the same /api/v2/document endpoint useList calls, old shape vs new: old (unscoped, 500, due_date asc): 500 rows, 427 Moltbook, 0 open visible new (scoped, 2000, +modified desc): 918 rows, 117 To Do + 2 In Progress = 119 Per-project open counts now resolve correctly (Moltbook 119, GemZy 1, AI-Native PM 5, Control Plane 1, BenchPress 1), and the no-project view returns all 1,013 non-archived tasks. yarn typecheck and yarn lint both clean.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A project with 119 open tasks showed an empty board: Someday, Backlog, To Do and In Progress all read zero while Done showed hundreds.
The task list fetched every non-archived task with one unscoped query (
limit: 500,orderBy: 'due_date asc') and then filtered client-side, so the project chip could only reveal rows that happened to land in those 500. With 918 of 1,013 tasks in one project, the window filled with that project's completed work: 427 of the 500 rows returned were itsDonetasks, and the 513 rows cut at the boundary held 118To Do, 1In Progressand 4Blocked. No filter could bring them back.due_date ascdecided which rows survived truncation, which is arbitrary here because no task carries a due date.TasksPagesendsprojectto the server when one is selected; status, priority and assignee stay client-side so those toggles do not refetchdue_date asc, modified descin both list views, so a truncated window keeps recently-touched workProjectDetailPagewas already project-scoped but still truncated a 918-task projectProjectsTabderives per-project counts from its rows, so the short window was reporting wrong totals on every dashboard card, not just hiding tasksVerified against the live site through the same
/api/v2/documentendpointuseListcalls. Old shape returned 500 rows, 427 from the project, 0 of them open; new shape returns 918 rows, 117To Do+ 2In Progress. Per-project open counts resolve correctly and the no-project view returns all 1,013 non-archived tasks.yarn typecheckandyarn lintpass.2000 is a raised ceiling, not a fix: one project is at 918 and growing. Server-side pagination, or excluding
Donefrom the default board query, is the durable answer and belongs in its own PR.no-docsBefore
After
