Spend - Autocomplete suggestions are not displayed after typing "withdrawal-status"

[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: 9.4.32-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93895
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search

Action Performed:

1. Open the staging.new.expensify.com website.
2. Navigate to "Spend" > "Expenses"
3. Type "withdrawal-status:" on search input.
4. Note that no autocomplete suggestions are displayed.

Expected Result:

After typing "withdrawal-status:" on search input on spend, autocomplete suggestions should display: "never" alongside "pending", "cleared", and "failed" as options.

Actual Result:

After typing "withdrawal-status:" on search input on "Spend", no autocomplete suggestions appear.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203945_1783614189034.Withdrawal.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7203945

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #93895

[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/4be0c5920f375ab8a2b5069318141a964d4df972cd6dcb2db46dc192210efa76

[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]

Issue Analysis

This deploy blocker is very likely misattributed — PR #93895 is not the cause and should not be reverted on account of it. That PR only adds the enum value NEVER: 'never' plus 10 locale strings and two test updates. It touches no parser, hook, or rendering code, so it cannot make the whole withdrawal-status: suggestion list disappear.

The full autocomplete chain is correct in the current code, and there is no gate anywhere that could suppress all suggestions:

• Parser recognizes both withdrawalStatus and the hyphenated withdrawal-status, ordered before the generic status rule so it is never shadowed — autocompleteParser.peggy:94-98.
• Hook returns all SETTLEMENT_STATUS values (including never) for an empty value — useAutocompleteSuggestions.ts:402-410.
• Display renders the "Suggestions" section under a single length > 0 guard — no allowlist, no per-type filter, no per-key hide — SearchAutocompleteList.tsx:568-582.
• withdrawal-status is a valid filter for the EXPENSE data type — useAdvancedSearchFilters.ts:66-71.
• The unit test that asserts all four statuses (cleared, failed, never, pending) passes — useAutocompleteSuggestions.test.ts.

The withdrawal-status autocomplete feature itself was introduced back on 2026-05-07 (PR #88246), well before this release — so it is not a "new feature" from the blocked PR.

Recommended next step (verification, not a code fix): Static analysis cannot reproduce "zero suggestions," so this needs a runtime check on the failing build:

1. Confirm whether the pre-existing pending/cleared/failed suggestions appeared under the same flow before this PR. If they never showed either, this is a pre-existing/environment issue, not a regression from [Payment due @Ollyws] Add never value to withdrawal-status search filter #93895.
2. The report is on the Android Hybrid build (+ Windows Chrome). Verify the tested build wasn't running a stale/cached JS bundle — a bundle predating the compiled parser would explain no key being parsed and therefore no suggestions.
3. If it reproduces on a fresh web build with the current bundle, the root cause is elsewhere in the runtime (bundling/beta gate/data), not in this one-line enum addition — re-triage accordingly.

Investigation details

• PR [Payment due @Ollyws] Add never value to withdrawal-status search filter #93895 file list: src/CONST/index.ts (+1: NEVER: 'never'), src/languages/*.ts ×10 (+1 each), tests/unit/Search/SearchUIUtilsTest.ts, tests/unit/hooks/useAutocompleteSuggestions.test.ts. No component/parser/hook changes.
• SETTLEMENT_STATUS enum — CONST/index.ts:6563-6568.
• The search-input autocomplete uses the hook path (raw values like never), not the translated getWithdrawalStatusOptions path, so even a missing translation could not blank the list.
• SearchAutocompleteList is the only consumer of useAutocompleteSuggestions (grep-confirmed); getAutocompleteDisplayText is a trivial ${key}:${value} concat with no suppression logic.

Alternative explanations considered: context-gating by search type (ruled out — valid for EXPENSE and no display gate exists); parser shadowing by the generic status rule (ruled out — withdrawalStatus is ordered first, confirmed in the compiled autocompleteParser.js); a translation error throwing during render (ruled out — the input autocomplete path uses raw enum values, not translations).

---

Next Steps: Since the evidence points away from PR #93895, I'd recommend re-triaging this blocker rather than reverting. Reply with @MelvinBot <feedback> to refine, or ask me to verify the runtime behavior on web.

[ShridharGoel]

Reproducible in production?: N/A - new feature, doesn't exist in prod

withdrawal-status exists in prod, we just added a new never value there

[JS00001]

This is a keyword only searchbox, going to close this, the expected result is not expected