Task-App crashes on applying task filter.

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: V9.4.44
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/66164607/folder/13176922/120604858/1600128128
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: User Settings

Action Performed:

1. Launch app
2. Open workspace chat
3. Create a task
4. Go to spend - filter - type: task
5. Tap confirm and apply filter

Expected Result:

App must not crash on applying task filter.

Actual Result:

App crashes on applying task filter.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7216566_1784911308986.Screenrecorder-2026-07-24-22-04-25-743.mp4

logs (2).txt

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7216566

Issue Owner

Current Issue Owner: @shubham1206agra

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/0692e23174db4d021927be4d10ccacfdc63bfdb7310bab04174b458b36f645a4

https://platform.applause.com/services/links/v1/external/3934757b7a11f10cc0e4c11a91a721800d369199857b6e8d20721c1a4af36c65

[melvin-bot]

Triggered auto assignment to @flodnv (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (crash in Expensify/App when rendering task-type Search results)
Causing PR: Not conclusively identified — see candidates below (Low confidence)
Related Issues: None found

Recommendation: NEEDS INVESTIGATION

The crash is scoped to the App-side Search "type: task" render path, so this is a frontend deploy blocker and DeployBlockerCash should stay. However, none of the PRs in the current StagingDeployCash (v9.4.44) shows an obvious task-specific crash on code inspection, so I could not confidently name a single causing PR. The Sentry stack trace for new.expensify@9.4.44-0 will pinpoint it quickly.

Assigned: none — no causing PR reached medium confidence, so per triage policy I am not assigning contributors yet.
Labels: No change. DeployBlockerCash kept (App-side render crash; the label was auto-added by the bot). No label was removed.

📋 Detailed Analysis

Affected code path (verified against the checkout)

Applying type: task and confirming builds a type:task query, navigates to Search results, and renders the task list. The task-only render path is:

• getSections → getTaskSections — src/libs/SearchUIUtils.ts (dispatch at L3676, builder at L2567–2626)
• getSortedSections → getSortedTaskData — src/libs/SearchUIUtils.ts (L3809–3810, L4092)
• TaskListItem → TaskListItemRow (ActionCell calls canActionTask/completeTask, reads item.createdBy/item.assignee) — src/components/Search/SearchList/ListItem/TaskListItem.tsx, .../TaskListItemRow.tsx

getTaskSections defensively defaults assignee/createdBy to emptyPersonalDetails and passes reportAttributesDerivedValue correctly (the useSearchSnapshot CHAT/TASK gating at src/components/Search/hooks/useSearchSnapshot.ts L154 is correct), so no obvious null-deref stood out here.

Candidate PRs (only PRs in this checklist that touch the Search-results / task render path)

1. #96700 — "Fix empty view shows briefly when sorting" by @bernhardoj (Low). It rewrote isSearchDataLoaded in src/libs/SearchUIUtils.ts and dropped optional chaining on searchResults.search (accessing searchResults.search.type directly). At HEAD this has already been re-hardened to searchResults.search?.type (src/libs/SearchUIUtils.ts L4827–4838), so if the staging build predates that hardening it could throw. Not task-specific, though. Approvers: @JS00001, @aimane-chnaif.
2. #96672 — "refactor getDisplayNameForParticipant function to use translate part 2" by @daledah (Low). Signature refactor across src/libs/ReportUtils.ts (getDisplayNamesWithTooltips, getIcons*) and src/libs/actions/Task.ts. getTaskSections calls getIcons(...) (src/libs/SearchUIUtils.ts L2612). Signatures are internally consistent at HEAD, but a stale/mis-ordered translate argument at runtime would produce a "translate is not a function" crash. Approvers: @luacmartins, @shubham1206agra.
3. #95953 — "feat: Insights Violations - add filter display + Empty state" by @nkdengineer (Low). Touches src/libs/SearchUIUtils.ts + SearchResults type, but changes are scoped to the expense has: filter / violation empty state, not the task path. Least likely. Approvers: @Ollyws, @neil-marcellini.

Verification performed

• Enumerated every PR + Mobile-Expensify PR in the v9.4.44 checklist and filtered file lists for Search/task/task-render helpers (ReportUtils, actions/Task, SearchList/ListItem, icon/avatar utils). Only the three PRs above touch the relevant code.
• Read getTaskSections, getSortedTaskData, getIcons/getIconsForTaskReport, TaskListItem, TaskListItemRow, and useSearchSnapshot — all internally consistent at HEAD (ea66d53).
• Could not run local git log/blame (repo is a depth-1 shallow checkout) and the GitHub blame API timed out on the large SearchUIUtils.ts, so per-line PR attribution wasn't possible.

What would resolve this fast

1. Paste the Sentry stack trace for new.expensify@9.4.44-0 (staging) for this crash — the top frame will name the exact file/function.
2. If the trace points at isSearchDataLoaded/Search-results loading → revert or CP the hardening from Fix empty view shows briefly when sorting #96700.
3. If it points at getIcons/getDisplayNames*/translate → revert refactor getDisplayNameForParticipant function to use translate part 2 #96672.

@bernhardoj @daledah @nkdengineer — could one of you (or the deployer) attach the Sentry trace so we can confirm which of the above is the culprit? Note: the tester's device is Android app on v9.4.44 (the staging build); the "reproducible in production" flag is likely inaccurate since 9.4.44 is not yet in production.