[$250] Search - Task cannot be found via Search

[jponikarchuk]

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.3.66-2
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/folder/13176964/test-cases/41237758
Email or phone of affected tester (no customers): pater.jarek@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Web macOS 26.4.1 Safari
App Component: Search

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Go to any conversation
3. Create a task with a unique name
4. Navigate to Search (command+K)
5. Enter the name of the task that was just created

Expected Result:

User is able to see the created task in the search results, tap on it, and is redirected to the correct task.

Actual Result:

Created task is not displayed in the search results, so it is not possible to open the task from Search.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051389000263918547
• Upwork Job ID: 2051389000263918547
• Last Price Increase: 2026-05-04

[MelvinBot]

Proposal

What is the root cause of that problem?

Tasks are created with NOTIFICATION_PREFERENCE.HIDDEN for all participants (Task.ts:132, ReportUtils.ts:8687-8698). The Cmd+K search calls getSearchOptions with excludeHidden: true. The excludeHidden filter has two branches: one for threads and one for non-threads. Tasks fall into the non-thread branch because isChatThread requires type === 'chat' but tasks have type === 'task'. Tasks also have no chatType, so they don't match the SELF_DM or POLICY_ADMINS exemptions. The filter then checks the participant's notificationPreference, finds it's HIDDEN, and excludes the task.

What changes do you think we should make in order to solve the problem?

Add isTaskReport as an exemption in the excludeHidden filter at OptionsListUtils/index.ts:2517-2521, similar to how SELF_DM and POLICY_ADMINS are already exempted. Tasks intentionally use HIDDEN to suppress push notifications, not to hide them from search. The fix would add a check like report.item?.type !== CONST.REPORT.TYPE.TASK to the non-thread hidden filter condition.

What alternative solutions did you explore? (Optional)

Changing the notification preference at task creation time (from HIDDEN to something else) was considered but rejected — HIDDEN is intentionally used to suppress notifications for tasks, and changing it would have broader side effects on task notification behavior.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ShridharGoel (External)

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user creates a task and then searches for it by name using the Search interface (command+K or the Search tab), the task does not appear in the search results, making it impossible to open a task directly from Search.

What is the root cause of that problem?

The Search page (the full results view navigated to when submitting a query) sends a typed query to the backend with type:expense as the default search data type. Tasks are a separate data type (type:task), so a keyword-only query such as "My task name" is sent to the server as type:expense keyword:"My task name", and the backend correctly returns no results because tasks are not expenses.

The root cause is in buildSearchQueryJSON / buildSearchQueryString in src/libs/SearchQueryUtils.ts. When the user types a plain keyword and submits the search (via submitSearch in SearchRouter.tsx), the query string has no explicit type filter. The parser defaults the type field to CONST.SEARCH.DATA_TYPES.EXPENSE (see the filtersForm[FILTER_KEYS.TYPE] assignment on line 1329 which falls back to CONST.SEARCH.DATA_TYPES.EXPENSE when no type is recognized). This hardcoded default means a plain keyword search never crosses into the task data type namespace. The autocomplete suggestions in the SearchRouter popup do show task reports (because getSearchOptions in OptionsListUtils/index.ts is called with includeTasks: true), so tasks appear as autocomplete suggestions — but clicking them navigates directly to ROUTES.REPORT_WITH_ID rather than a Search page, so that path works. The failure is specifically when the user submits the query to the Search results page, which restricts results to the expense type.

App/src/libs/SearchQueryUtils.ts

Lines 1328 to 1329 in 63b1a3a

	const [typeKey, typeValue] = Object.entries(CONST.SEARCH.DATA_TYPES).find(([, value]) => value === queryJSON.type) ?? [];
	filtersForm[FILTER_KEYS.TYPE] = typeValue ? queryJSON.type : CONST.SEARCH.DATA_TYPES.EXPENSE;

What changes do you think we should make in order to solve the problem?

The default search type should either be broadened to include tasks, or the keyword search should fan out across multiple types. The most targeted and backwards-compatible fix is to change the default data type used when no type is explicitly provided in the query from CONST.SEARCH.DATA_TYPES.EXPENSE to a new "all" or "any" type that covers expenses, chats, invoices, and tasks simultaneously. However, since no such wildcard type currently exists in the backend contract, the practical fix is to make the Search results page include tasks when the active query is a plain keyword search with no explicit type.

Concretely, in src/libs/SearchQueryUtils.ts, the getQueryWithUpdatedValues function (which is called by submitSearch before navigating to the Search page) should detect when the parsed query contains a keyword filter but no explicit type filter provided by the user, and in that case the search should not lock the type to expense. One clean approach is to recognize that when a user types a free-form keyword in the SearchRouter, the intent is a global search — not an expense search — and to navigate to the Search page with multiple type queries (e.g., type:expense keyword:X and type:task keyword:X merged) or to use a dedicated global-search entry point. The minimum viable fix is to add type:task coverage in the keyword search path by checking isTaskReport on each autocomplete result and, when the user selects the "Search for X" item, building a query that does not constrain the type field, allowing the backend to search across all types.

A more targeted fix is in buildSearchQueryString in src/libs/SearchQueryUtils.ts: when queryJSON.type is not set (i.e., the user did not explicitly filter by type), do not emit a type: token at all, and update the backend call in src/libs/actions/Search.ts / openSearchPage to omit the type parameter — letting the server return results across all data types when no type is specified. This would also require updating src/libs/SearchUIUtils.ts to handle responses that mix different data types in a single result set, or alternatively to fan out into separate typed queries client-side.

App/src/libs/SearchQueryUtils.ts

Lines 1856 to 1867 in 63b1a3a

	function getQueryWithUpdatedValues(query: string, shouldSkipAmountConversion = false) {
	const queryJSON = buildSearchQueryJSON(query);
	if (!queryJSON) {
	Log.alert(`${CONST.ERROR.ENSURE_BUG_BOT} user query failed to parse`, {}, false);
	return;
	}
	const computeNodeValue = (left: ValueOf<typeof CONST.SEARCH.SYNTAX_FILTER_KEYS>, right: string | string[]) => getUpdatedFilterValue(left, right, shouldSkipAmountConversion);
	const standardizedQuery = traverseAndUpdatedQuery(queryJSON, computeNodeValue);
	return buildSearchQueryString(standardizedQuery);
	}

What alternative solutions did you explore? (Optional)

An alternative is to add a "Search in Tasks" shortcut in the SearchRouter similar to how "Search in " contextual suggestions work, so that when a user is viewing a task the contextual suggestion would use type:task. This partially addresses discoverability but does not help with the general case where the user searches from any context. Another alternative is to show a "Did you mean to search tasks?" prompt on the Search results page when a keyword search returns no expense results — but this is a UX workaround rather than a fix.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022051389000263918547

[oqildev]

Proposal

What is the root cause of that problem?

When a user creates a Task inside a chat in New Expensify, the task is persisted as its own Onyx Report with type === CONST.REPORT.TYPE.TASK (the reportName holds the task title, and parentReportID/parentReportActionID link it back to the chat where it was created).

The Cmd+K SearchRouter (src/components/Search/SearchRouter/SearchRouter.tsx) builds its inline autocomplete suggestions by feeding the local reports collection through the option builder in src/libs/OptionsListUtils.ts (the getSearchOptions / getValidOptions path that is consumed via the SearchRouter's autocomplete hook). That builder iterates reports and constructs OptionData rows used both for display and for client-side substring matching against the typed query.

Two things break for tasks specifically:

1. The getValidOptions filter accepts an includeTasks flag whose default is false. The SearchRouter call site does not opt into includeTasks: true, so every report whose type === CONST.REPORT.TYPE.TASK is dropped before it ever reaches the matcher — that is why typing the exact task title returns nothing.
2. Even if a task slipped through, createOption for a task report composes text / searchText from the participants/alternateText, not from getReportName(report) (which is the actual task title). So the typed query would still need to match a participant rather than the title the user just gave the task.

The end result is what the bug report describes: a freshly created Task is unreachable from Cmd+K, even though the same report renders fine in the LHN and is openable by URL.

What changes do you think we should make in order to solve the problem?

Keep the change scoped to the SearchRouter recent-reports pipeline; do not touch the LHN, the Reports page tabs, or the server-side Search query parser.

1. In src/components/Search/SearchRouter/SearchRouter.tsx (and the autocomplete hook it delegates to — useSearchAutocomplete / the local getOptions helper colocated under src/components/Search/SearchRouter/), pass includeTasks: true when invoking the OptionsListUtils.getSearchOptions / getValidOptions call. This is the same pattern used by other consumers that legitimately need tasks (e.g., task-assignee selection).

2. In src/libs/OptionsListUtils.ts, in createOption (the branch that handles report-shaped options), when the report is a task report (isTaskReport(report) from ReportUtils), set the option's text and the substring-matchable searchText to the task title via getReportName(report). Today text falls back to participant-based names for task reports, which is why the title never participates in matching.

3. In the same file's matcher (filterReports / filterAndOrderOptions), include the task's title field in the haystack used for substring comparison. Folding it into the existing searchText from step 2 is enough — no new field is required.

4. Add a small icon/sub-title hint so a task suggestion is visually distinguishable from a chat in the dropdown (re-use Expensicons.Task and the existing alternateText slot to show the parent chat name). This avoids regressing the design while making the new entry obviously tappable.

No backend or SearchParser changes are needed — this bug is purely about the local autocomplete source missing tasks. After (1)–(3), tapping a result navigates correctly because the option already carries reportID and the existing Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID)) handler in SearchRouterList works for task reports unchanged.

What alternative solutions did you explore? (Optional)

• "Fix it on the server by adding type:task to the default search query." This would be tempting but wrong: the SearchRouter inline dropdown is populated from the local Onyx report collection before any server call is made, and the user reports the failure happens immediately on typing. Touching the server query would also pollute the Reports tab default view, which already has a separate Task tab. The fix belongs in OptionsListUtils.ts and the SearchRouter call site, not in SearchParser or the API.
• "Just include the task in the LHN search, the user can find it there." Out of scope and contradicts the bug — Cmd+K is the documented entry point and is what the regression test (BrowserStack TC 41237758) covers.
• A future contributor may propose flipping the includeTasks default to true inside getValidOptions itself. That is risky because other call sites (NewChatPage, IOU participant pickers, etc.) deliberately exclude tasks from their pickers and would silently regress. Opting in at the SearchRouter call site is the minimal, safe change.

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user searches for a task by typing its name in Search (command+K), the task does not appear in results even when the search string is a substring of the task title. The expected behavior is that partial matches on task titles should be found, just as they are for other text fields like merchant names and transaction descriptions. This affects task discoverability on Web macOS and likely all platforms.

What is the root cause of that problem?

The bug originates in src/libs/SearchQueryUtils.ts in the TEXT_SEARCH_FIELDS constant at line 2070. This set controls which filter keys receive the eq → contains operator normalization when queries are serialized for the backend. Currently, TEXT_SEARCH_FIELDS includes only MERCHANT and DESCRIPTION:

const TEXT_SEARCH_FIELDS = new Set<string>([CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT, CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION]);

When a user types a task name in Search, the query parser produces a title:<name> filter node with an eq operator. The serializeQueryJSONForBackend function calls applyContainsOperatorToTextFields to traverse the AST and upgrade eq to contains only for fields in TEXT_SEARCH_FIELDS. Because TITLE is absent from this set, the title:<name> query is sent to the backend as an exact-match query. The backend finds nothing unless the search string exactly matches the complete task title, so partial matches fail.

The same missing-field problem occurs in the rawFilterList code path at line 2113, which also checks TEXT_SEARCH_FIELDS.has(filter.key). By design, TITLE is already peer-grouped with MERCHANT and DESCRIPTION in buildFilterFormValuesFromQuery at line 1082, confirming it belongs in TEXT_SEARCH_FIELDS.

What changes do you think we should make in order to solve the problem?

1. File: src/libs/SearchQueryUtils.ts
   Function: TEXT_SEARCH_FIELDS (module-level constant, line 2070)
   Edit: Add CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE to the TEXT_SEARCH_FIELDS set. Change the constant from a two-element set (MERCHANT, DESCRIPTION) to a three-element set that also includes TITLE. This ensures that both the AST traversal in applyContainsOperatorToTextFields (line 2078) and the rawFilterList map (line 2113) will normalize title:<name> queries from eq to contains, allowing the backend to perform substring matching instead of exact matching.
   Exact code:

   const TEXT_SEARCH_FIELDS = new Set<string>([CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT, CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION, CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE]);
   

Blast radius: Isolated to serializeQueryJSONForBackend. The TEXT_SEARCH_FIELDS set is consumed only within that function via applyContainsOperatorToTextFields and the rawFilterList map. Callers (search() in actions/Search and useSearchBulkActions) will benefit from the fix with no adverse side-effects, since TITLE is a text search field by design.

What alternative solutions did you explore? (Optional)

Hardcoding an additional TITLE check inside applyContainsOperatorToTextFields would fix only the AST path (line 2078) and miss the identical TEXT_SEARCH_FIELDS.has(filter.key) check in the rawFilterList map (line 2113), leaving task searches via that code path still broken. The TEXT_SEARCH_FIELDS set is the canonical single source for this normalization, so it is the correct place to make the fix.

[github-actions]

⚠️ @oqildev Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The task is missing from the Cmd+K SearchRouter autocomplete pipeline before the user can select it.

Task creation stores the optimistic task report with HIDDEN notification preference at Task.ts#L125-L133, and buildOptimisticTaskReport applies that same hidden preference to the task participants at ReportUtils.ts#L8680-L8698.

SearchRouter does already use getSearchOptions(), and that path already opts into task reports with includeTasks: true at OptionsListUtils/index.ts#L2779-L2792. However, the same SearchRouter options path also passes excludeHidden: true, and the hidden-report filter removes every non-thread report whose current-user participant has hidden notification preference at OptionsListUtils/index.ts#L2512-L2525. Task reports are not chat threads, and ordinary tasks usually do not have the SELF_DM or POLICY_ADMINS chat-type exemptions, so they are filtered out.

There is a second missing case for the exact flow in the recording: the tester creates a task without selecting an assignee. For task reports, getParticipantsAccountIDsForDisplay() returns only managerID, and returns an empty list when the task has no assignee at ReportUtils.ts#L3150-L3155. processReport() then drops any non-room report with no display participant before it becomes a search option at OptionsListUtils/index.ts#L1432-L1437. So an unassigned hidden task is excluded twice.

What changes do you think we should make in order to solve the problem?

Fix the shared options pipeline so task reports can be represented and searched by title in SearchRouter.

• In processReport(), when a report is a task report with no assignee-derived display account ID, use the task owner as the display account ID so unassigned tasks can still become SearchOption rows.
• In the excludeHidden filter inside getValidOptions(), exempt task reports from the hidden-notification exclusion. For tasks, HIDDEN is used to suppress notification behavior, not to hide the task from Cmd+K search.
• Add a unit test in tests/unit/OptionsListUtilsTest.tsx covering a hidden unassigned task report searched by title.

Tests to add:

• getSearchOptions() returns a task report whose current-user participant notification preference is HIDDEN.
• The same test should use a task with managerID: 0 so the unassigned-task path is covered.

A hidden-only fix is incomplete because it still misses the unassigned-task flow shown in the recording: processReport() drops unassigned tasks before the hidden filter runs.

Changing the SearchQueryUtils backend serialization path is the wrong surface for this bug. The recording shows the Cmd+K autocomplete list failing to include the local task option, and SearchRouter already routes selected report options directly to ROUTES.REPORT_WITH_ID.

Changing task creation to use a non-hidden notification preference would be too broad because hidden task notification preference is intentional task behavior.

Demo

Screen.Recording.2026-05-05.at.9.47.36.AM.mov

What alternative solutions did you explore? (Optional)