Tasks: List does not render with 1,000 Tasks on phone #1240

Open
opened 2026-10-06 22:55:31 +00:00 by kayg · 2 comments
Owner

Reproduction: 2026-10-07, local production SPA and prebuilt release server. The existing apps/web/e2e/tasks-perf.mjs profile seeds 1,000 standalone Tasks through the Notes API, uses Chromium CPU throttling at 4x, and opens the phone-width Tasks routes.

Command settings:
TASKS_PERF_ITEMS=1000 TASKS_PERF_RUNS=3 TASKS_PERF_BURST_SECONDS=5
TASKS_PERF_MEASUREMENT="local release server and production SPA, 1k Task data"

The profile completed all three 390 px Board readiness runs, then waited 180 seconds for the first .task-list tbody tr at 390 px. No List row became visible before the timeout. There is no prior Tasks UI route baseline in docs/perf/baseline.json.

Exact failure:
locator.waitFor: Timeout 180000ms exceeded.
waiting for locator('.task-list tbody tr').first() to be visible
at measureRoute (apps/web/e2e/tasks-perf.mjs:69:39)

Evidence file: this file. The failed profile output was not written because the route did not become ready; the isolated benchmark server removed its temporary data when the run exited. This is at least a 180 s time-to-content failure at 1,000 real Tasks on the phone List route. Board view did render.
Severity: major performance/usability issue. Recheck with a production screenshot and compare the List fetch/render split before choosing a fix.

Reproduction: 2026-10-07, local production SPA and prebuilt release server. The existing `apps/web/e2e/tasks-perf.mjs` profile seeds 1,000 standalone Tasks through the Notes API, uses Chromium CPU throttling at 4x, and opens the phone-width Tasks routes. Command settings: TASKS_PERF_ITEMS=1000 TASKS_PERF_RUNS=3 TASKS_PERF_BURST_SECONDS=5 TASKS_PERF_MEASUREMENT="local release server and production SPA, 1k Task data" The profile completed all three 390 px Board readiness runs, then waited 180 seconds for the first `.task-list tbody tr` at 390 px. No List row became visible before the timeout. There is no prior Tasks UI route baseline in `docs/perf/baseline.json`. Exact failure: locator.waitFor: Timeout 180000ms exceeded. waiting for locator('.task-list tbody tr').first() to be visible at measureRoute (apps/web/e2e/tasks-perf.mjs:69:39) Evidence file: this file. The failed profile output was not written because the route did not become ready; the isolated benchmark server removed its temporary data when the run exited. This is at least a 180 s time-to-content failure at 1,000 real Tasks on the phone List route. Board view did render. Severity: major performance/usability issue. Recheck with a production screenshot and compare the List fetch/render split before choosing a fix.
Author
Owner

Correction after source review: this is not confirmed as an app rendering regression. tasks-perf.mjs hardcodes When/Deadline dates 2026-10-02 and 2026-10-04; on this run (2026-10-07) the default /tasks view is Next 7 days, so it filtered every fixture out. The 390 px Board shell rendered because the profile waits for .task-board, while the List wait for an actual row timed out. The 180 s result is therefore a benchmark-fixture false positive. I am leaving this issue open as required and fixing the fixture separately; the rerun will determine whether a real List performance issue remains.

Correction after source review: this is not confirmed as an app rendering regression. `tasks-perf.mjs` hardcodes When/Deadline dates `2026-10-02` and `2026-10-04`; on this run (2026-10-07) the default `/tasks` view is Next 7 days, so it filtered every fixture out. The 390 px Board shell rendered because the profile waits for `.task-board`, while the List wait for an actual row timed out. The 180 s result is therefore a benchmark-fixture false positive. I am leaving this issue open as required and fixing the fixture separately; the rerun will determine whether a real List performance issue remains.
Author
Owner

Correction: the rerun after #1243 changed the Task dates to run-relative values, but the profile still opened /tasks?layout=list without view=next-7-days. TasksWorkspace defaults to Inbox, and tasksForView excludes active Tasks that have a scheduled or due date from Inbox. Therefore the 180-second wait for a List row did not establish a rendering defect. The benchmark route bug is filed separately as #1246. I am leaving this issue open as required; it has no confirmed application defect.

Correction: the rerun after #1243 changed the Task dates to run-relative values, but the profile still opened `/tasks?layout=list` without `view=next-7-days`. TasksWorkspace defaults to Inbox, and `tasksForView` excludes active Tasks that have a scheduled or due date from Inbox. Therefore the 180-second wait for a List row did not establish a rendering defect. The benchmark route bug is filed separately as #1246. I am leaving this issue open as required; it has no confirmed application defect.
Commenting is not possible because the repository is archived.
No labels
No milestone
No project
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal-v0#1240
No description provided.