fix desktop tasks filter showing wrong results

[krushnarout]

Task filters not working properly — 14 Todos but only 1 showing, other filters also broken.

Bug demo:

Screen.Recording.2026-03-30.at.9.23.45.AM.mov

Root cause: Categorization always applied 7-day cutoff even without "Last 7 days" filter active.

Fix: Gate the 7-day cutoff on the last7Days filter; load completed tasks when "All" is selected.

After fix:

Screen.Recording.2026-03-30.at.9.26.57.AM.mov

Closes #6168

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR fixes a desktop task-filter regression where selecting "All" (or any non-status filter) would show far fewer tasks than expected. Two root causes are addressed: the 7-day categorization cutoff was always active instead of being gated on the last7Days filter, and completed tasks were never loaded unless an explicit "Done" status filter was selected. The run.sh tunnel setup is also reordered so the Cloudflare tunnel starts after .env is loaded, ensuring BACKEND_PORT has the correct value.

• Core fix (TasksPage.swift): applySevenDayCutoff is now conditioned on selectedTags.contains(.last7Days), matching the intended Flutter behaviour.
• Completed-task loading (TasksPage.swift): The else branch in the selectedTags observer triggers loadCompletedTasks() when no status filter is active, ensuring "All" shows both todo and done tasks.
• In-memory date-filter fallback (TasksPage.swift): A guard filteredFromDatabase.isEmpty && hasDateFilters applies date filters manually during the brief async window before the SQLite results arrive, preventing stale tasks from bleeding through transiently.
• run.sh reorder: Tunnel startup moved to after .env loading; the now-incorrect :-8080 fallback (the real default is 10201) is removed.
• Minor: The loadMoreFiltered function duplicates the categorization logic with unnecessary More-suffixed variable names; loadCompletedTasks() may fire redundantly when non-status filters are simultaneously active.

Confidence Score: 5/5

Safe to merge — the fix correctly targets the root cause and all remaining findings are minor style/efficiency suggestions.

Both root causes of the reported bug are addressed correctly. The run.sh change is a net improvement (correct port, correct ordering). The only remaining concerns are a redundant network call under certain filter combinations and an unnecessary variable-name suffix in loadMoreFiltered — neither affects correctness.

No files require special attention; TasksPage.swift has minor style items but no blocking issues.

Important Files Changed

Filename	Overview
desktop/Desktop/Sources/MainWindow/Pages/TasksPage.swift	Fixes two root causes of the tasks-filter bug: (1) gates the 7-day categorization cutoff on the last7Days filter instead of always applying it; (2) triggers loadCompletedTasks when "All" (no status filter) is selected; (3) adds an in-memory date-filter fallback for the async SQLite query window. Minor issues: duplicate variable suffix in loadMoreFiltered and a potentially redundant network call when non-status filters are simultaneously active.
desktop/run.sh	Moves the Cloudflare tunnel startup to after .env loading so BACKEND_PORT is correctly set; removes the stale :-8080 fallback that used the wrong default port. No functional issues.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[selectedTags changed] --> B{hasStatusFilter?}
    B -- Yes --> C{wantsDone / wantsTodo / wantsDeleted?}
    C --> D[Load appropriate tasks from store]
    B -- No / All --> E[loadCompletedTasks NEW]
    A --> F{hasNonStatusFilters?}
    F -- Yes --> G[loadFilteredTasksFromDatabase - async SQLite]
    F -- No --> H[filteredFromDatabase cleared / recomputeDisplayCaches]
    G --> I{filteredFromDatabase populated?}
    I -- Yes --> J[sourceTasks = filteredFromDatabase]
    I -- No async window --> K[sourceTasks = getSourceTasks in-memory]
    K --> L{hasDateFilters?}
    L -- Yes --> M[applyDateFilters manually NEW]
    L -- No --> N[applyStatusFilters only]
    J --> O[applyStatusFilters]
    M --> P[sortTasks]
    N --> P
    O --> P
    P --> Q{last7Days in selectedTags? FIXED}
    Q -- Yes --> R[Skip incomplete tasks older than 7 days]
    Q -- No --> S[Include all tasks]
    R --> T[categorizedTasks]
    S --> T

Loading

_{Reviews (1): Last reviewed commit: "fix desktop tasks filter showing wrong r..." | Re-trigger Greptile}

[greptile-apps]

Redundant loadCompletedTasks when non-status filters are active

When selectedTags contains non-status filters (e.g. last7Days, a category), both loadCompletedTasks() (line 507) and loadFilteredTasksFromDatabase() (line 512) are fired concurrently. The SQLite query path already returns completed tasks, so the extra network call to loadCompletedTasks is only useful for populating the in-memory store during the brief async window before the database results arrive.

This is not wrong, but it means every filter-tag toggle that keeps no status filter will issue a completed-tasks network request even when the SQLite path will supply them moments later. Consider guarding with !showCompleted (already used in the status-filter branch above) to skip the redundant fetch:

Suggested change

	} else {
	// No status filter = "All" — load completed tasks so they show alongside todos
	Task { await store.loadCompletedTasks() }
	}
	} else {
	// No status filter = "All" — ensure completed tasks are present for the in-memory fallback
	if !showCompleted {
	Task { await store.loadCompletedTasks() }
	}
	}

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[greptile-apps]

Unnecessary "More" suffix on local variable names

applySevenDayCutoffMore and sevenDaysAgoMore are local variables inside loadMoreFiltered and have no naming conflict with variables in recomputeDisplayCaches (different function scope). The More suffix adds noise without aiding readability.

Suggested change

	let applySevenDayCutoffMore = selectedTags.contains(.last7Days)
	let sevenDaysAgoMore = Date().addingTimeInterval(-7 * 24 * 60 * 60)
	let applySevenDayCutoff = selectedTags.contains(.last7Days)
	let sevenDaysAgo = Date().addingTimeInterval(-7 * 24 * 60 * 60)

Then update the three usages of applySevenDayCutoffMore / sevenDaysAgoMore below accordingly.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}