[$250] Android - Spend - No error shown for Report ID and Keyword fields

[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.29-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94013
Email or phone of affected tester (no customers): sintayewhaylu01@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung A16/ Android 15
App Component: Other

Action Performed:

1. Open the Hybrid app.
2. Go to Spend.
3. Enter a very long text in the Keyword and Report ID fields.

Expected Result:

An error message is displayed when the text reaches the 15,000-character limit in both fields

Actual Result:

No error message is shown. The app simply stops accepting additional text after a long input.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7202237_1783454305604.video_2026-07-07_22-57-24.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074590487545643829
• Upwork Job ID: 2074590487545643829
• Last Price Increase: 2026-07-21

[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/b5be24a753a3c34b54d7ffec61cea9a2ba79b3f7dff1ae6ba7b5fd5b201cd768

[melvin-bot]

📣 @kovodokagu! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Proposal

What is the root cause of that problem?

The Keyword and Report ID advanced-search filters render through the shared TextInputFilterContent, which relies entirely on useTextFilterValidation to surface a character-limit error. Two things combine to hide the error:

1. Neither field has a dedicated limit. The FILTER_MAX_LENGTH map only defines limits for DESCRIPTION, MERCHANT, and TITLE. KEYWORD and REPORT_ID fall through to the default ?? CONST.MAX_COMMENT_LENGTH = 15000.
2. The boundary is inclusive. isValidInputLength returns isValid when valueByteLength <= byteLength. So at exactly 15,000 bytes the input is still "valid" → error is undefined → no errorText/hasError is shown. The characterLimitExceedCounter error only fires at 15,001+ bytes.

The result matches the report: the user reaches ~15,000 characters and no error appears, because the field is treated as valid right up to the limit.

Note on "the app stops accepting text"

The TextInput in TextInputFilterContent sets no maxLength prop (lines 49-64), and BaseTextInput doesn't default one either, so there is no explicit code-level truncation. The "stops accepting additional text after a long input" symptom is therefore most likely native/browser behavior when a single field holds a very large string, rather than an app-enforced cap. This is the one part of the report I couldn't tie to a specific line — hence medium confidence. Regardless of that detail, the missing-error behavior is fully explained by the two points above.

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

Give KEYWORD and REPORT_ID explicit, sensible limits in FILTER_MAX_LENGTH so the existing characterLimitExceedCounter error path is reached well before the field silently maxes out — exactly like DESCRIPTION/MERCHANT/TITLE do today:

• REPORT_ID should use a small limit (report IDs are short numeric strings, so 15,000 is nonsensical here).
• KEYWORD should get a defined limit rather than the 15,000 comment fallback.

This reuses the wired-up error copy and needs no new component logic. The exact limit values are a product decision.

If the intent is truly to error at 15,000 for these fields specifically, note that the <= boundary in isValidInputLength is shared by many fields, so changing it there is out of scope — adding per-field limits is the safer, pattern-consistent fix.

What alternative solutions did you explore? (Optional)

Setting a maxLength prop on the TextInput would hard-cap input but would not satisfy the expected result (an explicit error message) — it would just silently truncate, which is closer to the current buggy behavior than the fix.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95540) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 20:39:18 UTC.

Proposal

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

In the advanced search filters, the Keyword and Report ID fields never show a character-limit error. You just type until the input silently stops accepting more characters (on Android the native keyboard field cuts you off), so the "you've hit the 15,000-character limit" message the tester expected never appears.

What is the root cause of that problem?

The validation lives in useTextFilterValidation (src/components/Search/hooks/useTextFilterValidation.tsx). It looks up a per-field limit in FILTER_MAX_LENGTH, and if the field isn't in that map it falls back to CONST.MAX_COMMENT_LENGTH (15,000):

const maxLength = FILTER_MAX_LENGTH[filterKey] ?? CONST.MAX_COMMENT_LENGTH;

The map only has entries for DESCRIPTION, MERCHANT, and TITLE. Keyword and Report ID have no entry, so both resolve to 15,000. The error only fires once the trimmed byte length exceeds that (isValidInputLength uses <=). That's the whole problem: 15,000 bytes is not something you reach by typing on a phone, so the branch that would surface the error is effectively dead for these two fields. The fields that DO show an error (Merchant at 255, Description at 1,000, Title at 10,000) work through this exact same hook precisely because their limits are low enough to actually hit.

There's a second half to it. The filter <TextInput> in TextInputFilterContent.tsx gets no maxLength prop, so on the App side nothing caps the input. Elsewhere in the app the 15,000 limit is made reachable by capping the native input at MAX_COMMENT_LENGTH + 1 (see RNMarkdownTextInput.tsx) and the main search bar caps at SEARCH_QUERY_LIMIT (1,000) — but these advanced-filter inputs are plain RNTextInput (type='default') with no cap, so what stops the typing is Android's native EditText, not our code, and no error is ever rendered. Worth noting the same dropdown path (TextFilterPopup.tsx) shares the hook and has the same gap, and WITHDRAWAL_ID is a third filter key with the identical latent hole.

One thing to be careful about: I don't think 15,000 is a bug. Git history shows [REPORT_ID]: 1000 was added and then deliberately removed in commit 3cffd1411ca ("fix wrong length"), and the pre-refactor SearchFiltersKeywordPage/SearchFiltersReportIDPage both used characterLimit={CONST.MAX_COMMENT_LENGTH}. So 15,000 is the intended limit — the bug is that it's unreachable and produces no feedback, not that it's the wrong number.

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

Return the resolved maxLength from useTextFilterValidation alongside the error, then pass maxLength={limit + 1} to the <TextInput> in both TextInputFilterContent.tsx and TextFilterPopup.tsx. The +1 matches the pattern already used for MAX_COMMENT_LENGTH inputs across the app: it lets the user type one character past the limit so the validation hook fires and renders the error, instead of the native field silently swallowing the keystroke. This keeps 15,000 as the limit for Keyword/Report ID (and covers Withdrawal ID for free) while making the error actually appear on Android and everywhere else.

There's a real product choice buried here, so I want to flag it rather than assume. maxLength={limit + 1} shows the error the tester asked for. maxLength={limit} would hard-cap silently with no error — cleaner, but it contradicts the "expected: error message" in the report. I'd go with +1 to match the reported expectation, but happy to switch to a silent cap if that's the preferred behavior.

This area has no test asserting that Keyword/Report ID surface a limit error, which is how the gap survived #94013's validation restore. I'd add a case: value at the limit → no error, value at limit+1 → error shown.

What alternative solutions did you explore? (Optional)

Lowering Keyword/Report ID to a small limit like 1,000 — rejected, because 15,000 is the restored original and the 1,000 value for Report ID was explicitly pulled out as "wrong length," so that would be reintroducing a known-bad change. Changing isValidInputLength from <= to >= — rejected, it's a shared utility with a wide blast radius and it still wouldn't help, since the input would need to reach 15,000 for it to matter anyway.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 20:28:14 UTC.

Proposal

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

In Reports > Spend filters, entering a very long value in the Report ID or Keyword field never shows the character-limit error. The field silently stops accepting input instead, while the sibling text filters (Description, Merchant) show their limit errors correctly.

What is the root cause of that problem?

1. #94013 (merged 2026-07-07, the PR this regression QA ran against) added length validation for text filters. The error only fires when the value strictly EXCEEDS the limit — isValidInputLength treats byteLength <= maxLength as valid:
   

   App/src/libs/ValidationUtils.ts

   Lines 760 to 763 in c08f57f

   	function isValidInputLength(inputValue: string, byteLength: number) {
   	const valueByteLength = StringUtils.getUTF8ByteLength(inputValue);
   	return {isValid: valueByteLength <= byteLength, byteLength: valueByteLength};
   	}

2. FILTER_MAX_LENGTH has explicit entries only for description (1,000), merchant (255) and title (10,000). Report ID and Keyword are not in the map, so they fall back to CONST.MAX_COMMENT_LENGTH = 15,000 bytes:
   

   App/src/components/Search/hooks/useTextFilterValidation.tsx

   Lines 11 to 21 in c08f57f

   	const FILTER_MAX_LENGTH: Partial<Record<SearchTextFilterKeys, number>> = {
   	[CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION]: CONST.DESCRIPTION_LIMIT,
   	[CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT]: CONST.MERCHANT_NAME_MAX_BYTES,
   	[CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE]: CONST.TASK_TITLE_CHARACTER_LIMIT,
   	};
   	function useTextFilterValidation(filterKey: SearchTextFilterKeys, value: string | undefined, onError?: (error: string | undefined) => void) {
   	const {translate} = useLocalize();
   	const maxLength = FILTER_MAX_LENGTH[filterKey] ?? CONST.MAX_COMMENT_LENGTH;
   	const {isValid, byteLength} = isValidInputLength(value?.trim() ?? '', maxLength);
   	const error = !isValid ? translate('common.error.characterLimitExceedCounter', byteLength, maxLength) : undefined;

   
   

   App/src/CONST/index.ts

   Line 5055 in c08f57f

   MAX_COMMENT_LENGTH: 15000,

3. These filter inputs are plain text inputs with no maxLength — type defaults to 'default', so BaseTextInput renders a plain RNTextInput with maxLength={undefined} (this is not the markdown input, which would cap at MAX_COMMENT_LENGTH + 1):
   

   App/src/components/TextInput/BaseTextInput/implementation/index.native.tsx

   Lines 101 to 102 in c08f57f

   	const InputComponent = InputComponentMap.get(type) ?? RNTextInput;
   	const isMarkdownEnabled = type === 'markdown';

   
   So the error can only ever appear if the user physically gets MORE than 15,000 bytes into the field.

4. On Android that is impossible: the native field stops accepting input around 5,000 characters. #94013's own QA steps acknowledge this ("NOTE: Android natively has a max length of 5000"). That saturation is exactly the reported "app simply stops accepting additional text": byteLength plateaus at ~5,000, stays ≤ 15,000, isValid stays true, and the error never renders.

5. The structural cause: the 15,000 fallback is not a real contract for these fields — it is unreachable on Android and 15× larger than what the search pipeline itself accepts. Every text-filter value is serialized into the search query string, and both places a query is typed or re-edited are hard-capped at CONST.SEARCH_QUERY_LIMIT = 1,000:
   

   App/src/components/Search/SearchAutocompleteInput.tsx

   Line 226 in c08f57f

   maxLength={CONST.SEARCH_QUERY_LIMIT}

   
   

   App/src/components/Search/SearchPageHeader/SearchPageInput.tsx

   Line 67 in c08f57f

   maxLength={CONST.SEARCH_QUERY_LIMIT}

   
   Worse, SearchPageInput loads the current keyword filter back into that 1,000-capped input, so a keyword over 1,000 chars silently truncates on the next edit/submit:
   

   App/src/components/Search/SearchPageHeader/SearchPageInput.tsx

   Lines 36 to 43 in c08f57f

   	const keywordFilters = queryJSON.flatFilters.find((filter) => filter.key === CONST.SEARCH.SYNTAX_FILTER_KEYS.KEYWORD)?.filters ?? [];
   	const keywordQuery = keywordFilters.reduce((acc, keyword) => `${acc} ${sanitizeSearchValue(keyword.value.toString())}`, '').trim();
   	const [prevKeywordQuery, setPrevKeywordQuery] = useState('');
   	if (keywordQuery !== prevKeywordQuery) {
   	setTextInputValue(keywordQuery);
   	setPrevKeywordQuery(keywordQuery);
   	}

Affected paths — all of them read the same hook, so it is the single convergence point:

• Advanced-filters RHP/popover content (narrow + wide, all platforms):

  App/src/components/Search/FilterComponents/AdvancedFilters/TextInputFilterContent.tsx

  Line 45 in c08f57f

  const error = useTextFilterValidation(filterKey, value);

• Filter-bar popup (wide layout):

  App/src/components/Search/FilterDropdowns/TextFilterPopup.tsx

  Line 28 in c08f57f

  const error = useTextFilterValidation(filterKey, value);

• Report-field text filters:

  App/src/components/Search/FilterComponents/ReportField/ReportFieldText.tsx

  Line 22 in c08f57f

  const error = useTextFilterValidation(filterKey, value, onError);

• Fields hitting the buggy fallback: reportID and keyword (reported), plus withdrawalID, limit and per-policy report-field text filters — same latent bug:

  App/src/types/form/SearchAdvancedFiltersForm.ts

  Lines 24 to 32 in c08f57f

  	const TEXT_FILTER_KEYS = new Set<SearchTextFilterKeys>([
  	CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT,
  	CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION,
  	CONST.SEARCH.SYNTAX_FILTER_KEYS.REPORT_ID,
  	CONST.SEARCH.SYNTAX_FILTER_KEYS.KEYWORD,
  	CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE,
  	CONST.SEARCH.SYNTAX_FILTER_KEYS.WITHDRAWAL_ID,
  	CONST.SEARCH.SYNTAX_ROOT_KEYS.LIMIT,
  	]);

This chain explains every symptom: no error (threshold unreachable), input "stops accepting text" (native saturation, Samsung A16), and why only the two fallback fields were flagged while Description/Merchant errored fine (their explicit limits sit far below the saturation point).

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

One line in the hook — fall back to the query pipeline's real contract instead of MAX_COMMENT_LENGTH:

// src/components/Search/hooks/useTextFilterValidation.tsx
const maxLength = FILTER_MAX_LENGTH[filterKey] ?? CONST.SEARCH_QUERY_LIMIT; // was CONST.MAX_COMMENT_LENGTH

Any Report ID / Keyword (and withdrawalID / limit / report-field) value over 1,000 bytes now shows common.error.characterLimitExceedCounter (e.g. "1,050/1,000") on every platform — 1,000 is comfortably below Android's ~5,000 input ceiling, so the error is actually reachable, and Confirm/Apply stays blocked because all three consumers already gate on error. Update the fallback unit test at:

App/tests/unit/hooks/useTextFilterValidation.test.tsx

Lines 68 to 73 in c08f57f

	it('falls back to MAX_COMMENT_LENGTH for filters without a specific limit', () => {
	const length = CONST.MAX_COMMENT_LENGTH + 1;
	const value = 'x'.repeat(length);
	const {result} = renderValidationHook(CONST.SEARCH.SYNTAX_FILTER_KEYS.KEYWORD, value);
	expect(result.current).toBe(expectedError(length, CONST.MAX_COMMENT_LENGTH));
	});

Regression safety: Description/Merchant/Title keep their explicit limits, nothing else reads the fallback, and values ≤ 1,000 behave exactly as today.

Why the obvious spot fix fails: adding explicit reportID/keyword: 15000 map entries, or maxLength={15000} on the TextInput, cannot surface the error — it fires only when the value EXCEEDS the threshold, and on Android the field saturates near 5,000 chars so 15,000 is unreachable; a maxLength cap makes exceeding impossible on every platform (value ≤ cap ⇒ isValid always true), which reproduces the reported behavior verbatim. Changing the comparator to >= ("error when the text reaches the limit") doesn't fix the reported device either — the input never reaches 15,000 on Android — and it leaves validation blessing a 14,999-char keyword that the 1,000-capped query editor then silently truncates.

What alternative solutions did you explore? (Optional)

1. Explicit FILTER_MAX_LENGTH entries per key (e.g. a much smaller reportID limit, since report IDs are ~20 digits). Reasonable, but the fallback itself stays broken for withdrawalID, limit and report-field filters — the one-line fallback change covers them all, and tighter per-field caps can be layered on later.
2. >= comparator at 15,000 — rejected above: unreachable on Android, so it does not fix the bug.
3. Clamp every limit with Math.min(limit, SEARCH_QUERY_LIMIT) — would also make Title (10,000, likewise unreachable on Android's ~5,000 ceiling) consistent, but that changes an explicit mapping #94013 chose deliberately, so I'd keep it as a design follow-up rather than bundle it here.

[aswin-s]

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

On Android (Hybrid app) and Windows Chrome, when a user enters very long text in the Keyword or Report ID advanced-filter fields, no error message is shown. Instead, the app silently stops accepting additional characters near the 15,000-character limit. The expected behavior is a visible error (matching the pattern already working for Description and Merchant filters) when the byte length of the input reaches or exceeds CONST.MAX_COMMENT_LENGTH (15 000).

What is the root cause of that problem?

FILTER_MAX_LENGTH in [src/components/Search/hooks/useTextFilterValidation.tsx:11](https://github.com/Expensify/App/blob/c08f57f132045c840f58d846dda99d9d0caaa779/src/components/Search/hooks/useTextFilterValidation.tsx#L11)–15 maps filter keys to their byte-length thresholds:

const FILTER_MAX_LENGTH: Partial<Record<SearchTextFilterKeys, number>> = {
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION]: CONST.DESCRIPTION_LIMIT,   // 1 000
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT]:    CONST.MERCHANT_NAME_MAX_BYTES, // 255
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE]:       CONST.TASK_TITLE_CHARACTER_LIMIT, // 10 000
};

REPORT_ID and KEYWORD are absent. The hook falls back to CONST.MAX_COMMENT_LENGTH (15 000) via the ?? operator at line 19:

const maxLength = FILTER_MAX_LENGTH[filterKey] ?? CONST.MAX_COMMENT_LENGTH;

There are two compounding bugs:

Bug 1 — off-by-one in the validator. The byte-length check in [src/libs/ValidationUtils.ts:760](https://github.com/Expensify/App/blob/c08f57f132045c840f58d846dda99d9d0caaa779/src/libs/ValidationUtils.ts#L760)–763 uses <=:

return {isValid: valueByteLength <= byteLength, byteLength: valueByteLength};

This means a value whose byte length equals byteLength (e.g., exactly 15 000 bytes) is considered valid, so the error never fires at the limit boundary — only for input that has already exceeded it.

Bug 2 — Android input wall prevents exceeding the limit. On Android, the native EditText underlying React Native's TextInput (which has no explicit maxLength prop in these filter components) degrades in performance and effectively stops accepting new characters at roughly 15 000 characters. At that point the React-controlled value state is capped at ≤ 15 000 bytes; isValidInputLength(value, 15000) returns isValid: true for every render (because of the <= comparison), and the errorText prop in the TextInput is never set.

The two bugs interact: Bug 1 means the error cannot fire exactly at the limit; Bug 2 means typed ASCII input can never exceed it. Together they ensure the error never fires for typed input on Android or for ASCII input on any platform.

For the working filters (Description = 1 000, Merchant = 255), their limits are well below the Android input wall, so users can type past the threshold and the error fires normally.

Two render surfaces share this bug:

1. Mobile full-screen filter page — [src/components/Search/FilterComponents/AdvancedFilters/TextInputFilterContent.tsx:49](https://github.com/Expensify/App/blob/c08f57f132045c840f58d846dda99d9d0caaa779/src/components/Search/FilterComponents/AdvancedFilters/TextInputFilterContent.tsx#L49)–64, rendered via TextInputFilterContentPageWrapper (native) and TextInputFilterContentPopupWrapper (desktop advanced-filters sheet). The TextInput at line 49 carries errorText={error} and hasError={!!error} but no maxLength.

2. Web filter-bar dropdown — [src/components/Search/FilterDropdowns/TextFilterPopup.tsx:44](https://github.com/Expensify/App/blob/c08f57f132045c840f58d846dda99d9d0caaa779/src/components/Search/FilterDropdowns/TextFilterPopup.tsx#L44)–53, rendered by useSearchFiltersBar.tsx:115–119 for all isTextFilterKey entries (which includes KEYWORD and REPORT_ID). This TextInput also passes errorText={error} and hasError={!!error} but no maxLength. This is the Windows: Chrome path checked in the issue.

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

1. [src/libs/ValidationUtils.ts:760](https://github.com/Expensify/App/blob/c08f57f132045c840f58d846dda99d9d0caaa779/src/libs/ValidationUtils.ts#L760)–763 — change <= to < so the validator returns isValid: false when the byte length exactly equals the limit:

// before
return {isValid: valueByteLength <= byteLength, byteLength: valueByteLength};

// after
return {isValid: valueByteLength < byteLength, byteLength: valueByteLength};

This is the root fix. Once the validator treats value.length === limit as invalid, the error can fire the moment the user's input reaches the threshold — which is exactly what happens on Android (input walls at ~15 000 bytes) and is also the correct semantic (the limit is the maximum allowed, not an allowed value).

2. [src/components/Search/hooks/useTextFilterValidation.tsx:11](https://github.com/Expensify/App/blob/c08f57f132045c840f58d846dda99d9d0caaa779/src/components/Search/hooks/useTextFilterValidation.tsx#L11)–15 — add explicit entries for REPORT_ID, KEYWORD, and WITHDRAWAL_ID (also handled by TextInputFilterContent but currently absent):

const FILTER_MAX_LENGTH: Partial<Record<SearchTextFilterKeys, number>> = {
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION]:   CONST.DESCRIPTION_LIMIT,
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT]:      CONST.MERCHANT_NAME_MAX_BYTES,
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE]:         CONST.TASK_TITLE_CHARACTER_LIMIT,
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.REPORT_ID]:     CONST.MAX_COMMENT_LENGTH,
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.KEYWORD]:       CONST.MAX_COMMENT_LENGTH,
    [CONST.SEARCH.SYNTAX_FILTER_KEYS.WITHDRAWAL_ID]: CONST.MAX_COMMENT_LENGTH,
};

This makes the intent explicit, eliminates silent reliance on the ?? fallback, and ensures future changes to the default cannot silently change these fields' limits.

3. src/components/Search/FilterComponents/AdvancedFilters/TextInputFilterContent.tsx — forward maxLength to <TextInput> so the native component surfaces a visible cap and, together with the fix in step 1, allows the error to fire the moment input reaches the byte threshold:

const {maxLength} = useTextFilterValidation(filterKey, value); // export maxLength from hook, or re-derive it inline
// ...
<TextInput
    maxLength={maxLength}
    errorText={error}
    hasError={!!error}
    ...
/>

With the < fix in place, when typed input fills the native TextInput to exactly maxLength characters the validator now returns isValid: false and the error renders immediately.

4. src/components/Search/FilterDropdowns/TextFilterPopup.tsx — apply the same maxLength forwarding to the <TextInput> here. This is the web filter-bar popup (via useSearchFiltersBar) and is the surface affected on Windows: Chrome:

const error = useTextFilterValidation(filterKey, value);
// derive maxLength from same FILTER_MAX_LENGTH lookup or export it from hook
<TextInput
    maxLength={maxLength}
    errorText={error}
    hasError={!!error}
    ...
/>

5. TextInputFilterContentPopupWrapper (src/components/Search/FilterDropdowns/SearchAdvancedFiltersPopup/TextInputFilterContentPopupWrapper.tsx) renders TextInputFilterContent, so it gets the fix from step 3 for free. No direct change needed.

6. Unit tests — add/extend tests for useTextFilterValidation and isValidInputLength asserting:

• REPORT_ID and KEYWORD produce an error string when value byte length equals CONST.MAX_COMMENT_LENGTH (the at-limit case, now fixed by the < change).
• REPORT_ID and KEYWORD produce an error string when value byte length exceeds CONST.MAX_COMMENT_LENGTH.
• REPORT_ID and KEYWORD return undefined when value byte length is strictly below the limit.
• isValidInputLength returns isValid: false for input whose byte length equals byteLength (regression guard for the off-by-one fix).

What alternative solutions did you explore? (Optional)

• No-op explicit entries without fixing the validator — adding REPORT_ID/KEYWORD to FILTER_MAX_LENGTH without changing <= to < in isValidInputLength still produces no error for typed ASCII input: the Android wall caps the value at exactly 15 000 bytes, and isValidInputLength(value, 15000) returns isValid: true because 15000 <= 15000. The fix to the comparator is required.
• No-op explicit entries without maxLength forwarding — adding REPORT_ID/KEYWORD to FILTER_MAX_LENGTH without passing maxLength to TextInput documents intent but does not change runtime behavior: the ?? fallback already produces 15 000, and the Android input wall prevents the value from exceeding 15 000 bytes, so the error still never fires.
• Smaller limit for KEYWORD/REPORT_ID — not appropriate; the issue specification explicitly cites the 15 000-character limit as correct.
• Validation on blur only — would require a different hook design and deviates from the per-keystroke pattern used by all other text filter fields; not pursued.

[samranahm]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-08 01:45:49 UTC.

Proposal

What is the root cause of that problem?

When we open Spend > Advanced filters and type in the Keyword or Report ID field, the app should show an error after 15,000 characters. Instead, typing just stops and nothing is shown.

These two fields use shared components, not old separate pages:

• Mobile / full-screen filter: TextInputFilterContent.tsx
• Web filter popup: TextFilterPopup.tsx

Both already call useTextFilterValidation. That hook knows how to show characterLimitExceedCounter when text is over 15,000 characters.

The problem is timing. The error only shows when the value goes past 15,000 (15,001+). On Android, the native text field often stops accepting input around the limit before the value ever gets to 15,001. So the hook thinks the text is still valid and never shows an error.

Other inputs in the app (like comments) avoid this by setting maxLength to limit + 1 (15,001). That lets the user type one extra character, which triggers the validation error instead of a silent stop.

Keyword and Report ID never got that + 1 cap.

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

Keep the existing useTextFilterValidation hook as-is. Only add a maxLength of CONST.MAX_COMMENT_LENGTH + 1 (15,001) on the TextInput for Keyword and Report ID in both places where users can edit those fields.

When the user types the 15,001st character, the hook returns an error, the input shows it, and the Confirm / Apply button stays blocked.

File 1: TextInputFilterContent.tsx

Add this line after useTextFilterValidation:

const maxInputLength = filterKey === CONST.SEARCH.SYNTAX_FILTER_KEYS.KEYWORD || filterKey === CONST.SEARCH.SYNTAX_FILTER_KEYS.REPORT_ID ? CONST.MAX_COMMENT_LENGTH + 1 : undefined;

Pass it to the TextInput:

<TextInput
    ref={(ref) => {
        if (!autoFocus || !isTextInput(ref)) {
            return;
        }
        inputCallbackRef(ref);
    }}
    placeholder={label}
    value={value}
    errorText={error}
    hasError={!!error}
    onChangeText={setValue}
    maxLength={maxInputLength}
    accessibilityLabel={label}
    role={CONST.ROLE.PRESENTATION}
    containerStyles={[styles.ph5]}
/>

File 2: TextFilterPopup.tsx

Add the same line after useTextFilterValidation:

const maxInputLength = filterKey === CONST.SEARCH.SYNTAX_FILTER_KEYS.KEYWORD || filterKey === CONST.SEARCH.SYNTAX_FILTER_KEYS.REPORT_ID ? CONST.MAX_COMMENT_LENGTH + 1 : undefined;

Pass it to the TextInput:

<TextInput
    placeholder={label}
    value={value}
    errorText={error}
    hasError={!!error}
    onChangeText={setValue}
    maxLength={maxInputLength}
    accessibilityLabel={label}
    role={CONST.ROLE.PRESENTATION}
    containerStyles={[styles.ph5]}
/>

No changes are needed in useTextFilterValidation.tsx. Keyword and Report ID already fall back to CONST.MAX_COMMENT_LENGTH (15,000) there.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Solution Verification Result

Android.Native.mp4

[KJ21-ENG]

Proposal

What is the root cause of that problem?

PR #94013 added client-side validation for text search filters, but the rendered text-filter inputs do not provide an input window beyond the validation limit. The validation hook only produces an error after the value exceeds the max length, and Keyword / Report ID fall back to CONST.MAX_COMMENT_LENGTH (15,000).

App/src/components/Search/hooks/useTextFilterValidation.tsx

Lines 11 to 21 in c08f57f

	const FILTER_MAX_LENGTH: Partial<Record<SearchTextFilterKeys, number>> = {
	[CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION]: CONST.DESCRIPTION_LIMIT,
	[CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT]: CONST.MERCHANT_NAME_MAX_BYTES,
	[CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE]: CONST.TASK_TITLE_CHARACTER_LIMIT,
	};
	function useTextFilterValidation(filterKey: SearchTextFilterKeys, value: string | undefined, onError?: (error: string | undefined) => void) {
	const {translate} = useLocalize();
	const maxLength = FILTER_MAX_LENGTH[filterKey] ?? CONST.MAX_COMMENT_LENGTH;
	const {isValid, byteLength} = isValidInputLength(value?.trim() ?? '', maxLength);
	const error = !isValid ? translate('common.error.characterLimitExceedCounter', byteLength, maxLength) : undefined;

The advanced filter content, filter popup, and report-field text input all render errorText from useTextFilterValidation and block apply/confirm when error exists, but none of them passes a maxLength that allows the value to go past the validation limit. On Android, once input stops at the limit, the hook never sees an invalid value, so no error is shown.

App/src/components/Search/FilterComponents/AdvancedFilters/TextInputFilterContent.tsx

Lines 43 to 75 in c08f57f

	const label = translate(FILTER_VIEW_MAP[filterKey].labelKey);
	const {inputCallbackRef} = useAutoFocusInput();
	const error = useTextFilterValidation(filterKey, value);
	return (
	<View style={[styles.flex1, styles.justifyContentBetween, style]}>
	<TextInput
	ref={(ref) => {
	if (!autoFocus || !isTextInput(ref)) {
	return;
	}
	inputCallbackRef(ref);
	}}
	placeholder={label}
	value={value}
	errorText={error}
	hasError={!!error}
	onChangeText={setValue}
	accessibilityLabel={label}
	role={CONST.ROLE.PRESENTATION}
	containerStyles={[styles.ph5]}
	/>
	<Button
	style={[styles.ph5, styles.pb5]}
	success
	large={largeButton}
	text={translate('common.confirm')}
	pressOnEnter
	onPress={() => {
	if (error) {
	return;
	}
	onChange(value);

App/src/components/Search/FilterDropdowns/TextFilterPopup.tsx

Lines 28 to 53 in c08f57f

	const error = useTextFilterValidation(filterKey, value);
	const applyChanges = () => {
	if (error) {
	return;
	}
	updateFilterForm({[filterKey]: value} as Partial<SearchAdvancedFiltersForm>);
	closeOverlay();
	};
	return (
	<BasePopup
	label={label}
	onApply={applyChanges}
	applySentryLabel={`Search-FilterPopupApply-${filterKey}`}
	>
	<TextInput
	placeholder={label}
	value={value}
	errorText={error}
	hasError={!!error}
	onChangeText={setValue}
	accessibilityLabel={label}
	role={CONST.ROLE.PRESENTATION}
	containerStyles={[styles.ph5]}
	/>

App/src/components/Search/FilterComponents/ReportField/ReportFieldText.tsx

Lines 20 to 34 in c08f57f

	function ReportFieldText({filterKey, field, value, onChange, onError}: ReportFieldTextProps) {
	const styles = useThemeStyles();
	const error = useTextFilterValidation(filterKey, value, onError);
	return (
	<TextInput
	placeholder={field.name}
	value={value}
	errorText={error}
	hasError={!!error}
	onChangeText={onChange}
	accessibilityLabel={field.name}
	role={CONST.ROLE.PRESENTATION}
	containerStyles={[styles.ph5, styles.pv2]}
	/>

The shared BaseTextInput is not the right layer for this behavior because it just forwards the caller's maxLength to the native/web input, and many other callers intentionally use maxLength as a hard cap.

App/src/components/TextInput/BaseTextInput/implementation/index.native.tsx

Lines 436 to 440 in c08f57f

	multiline={isMultiline}
	maxLength={maxLength}
	onFocus={onFocus}
	onBlur={onBlur}
	onChangeText={setValue}

App/src/components/TextInput/BaseTextInput/implementation/index.tsx

Lines 519 to 523 in c08f57f

	]}
	multiline={isMultiline}
	maxLength={maxLength}
	onFocus={onFocus}
	onBlur={onBlur}

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

Expose the search text-filter max length from useTextFilterValidation.tsx, for example getTextFilterMaxLength(filterKey), and have the hook use that helper so validation and input caps share the same source of truth.

Then update all three useTextFilterValidation call sites:

• TextInputFilterContent: compute the text filter limit and pass maxLength={limit + CONST.ADDITIONAL_ALLOWED_CHARACTERS} to the TextInput.
• TextFilterPopup: do the same for the filter-chip popup input.
• ReportFieldText: do the same for dynamic text report-field filters, since it uses the same validation hook and onError flow.

CONST.ADDITIONAL_ALLOWED_CHARACTERS already exists for the "allow a little past the search limit" pattern, so Keyword and Report ID can accept 15,001-15,020 characters, render Character limit exceeded (15001/15000), and keep Apply/Confirm blocked through the existing error checks.

App/src/CONST/index.ts

Lines 6041 to 6045 in c08f57f

	/**
	* The count of characters we'll allow the user to type after reaching SEARCH_MAX_LENGTH in an input.
	*/
	ADDITIONAL_ALLOWED_CHARACTERS: 20,

Test coverage:

• Update useTextFilterValidation tests to cover Report ID / Keyword defaulting to CONST.MAX_COMMENT_LENGTH and the exported max-length helper.
• Add focused component coverage for TextInputFilterContent and TextFilterPopup verifying the rendered TextInput receives maxLength = validationLimit + CONST.ADDITIONAL_ALLOWED_CHARACTERS, shows the validation error at validationLimit + 1, and does not apply while invalid.
• Manually verify on Android that Spend > Keyword and Report ID fields show the character-limit error after the 15,000-character limit instead of silently refusing more input.

What alternative solutions did you explore? (Optional)

I considered changing BaseTextInput to automatically allow extra characters whenever maxLength is set, but that would affect unrelated inputs that need a strict cap, such as codes, SSN fields, and numeric inputs. Keeping the overflow allowance in the search text-filter layer fixes the validated search fields without weakening hard caps elsewhere.

[ashu75575]

Proposal

What is the root cause of that problem?

In the Advanced Search Filters for Keyword, Report ID, and other text-based filters, the underlying TextInput lacks a maximum length validation. When a user pastes or types a very long string (> 15,000 characters) into these fields, the app's input buffer either hangs or silently stops accepting characters natively. Furthermore, no validation error is shown in the UI because TextInputFilterComponents and its parent TextInputFilterContent do not check the input length against CONST.MAX_COMMENT_LENGTH (15,000 characters) nor pass any errorText to the TextInput.

TextInputFilterContent.tsx
index.tsx (FilterComponents)

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

We should add character limit validation for text-based Advanced Search Filters by checking if the value exceeds CONST.MAX_COMMENT_LENGTH (15,000 characters).

1. In src/components/Search/FilterComponents/index.tsx:
   Update TextInputFilterComponents to evaluate if the input length exceeds CONST.MAX_COMMENT_LENGTH and pass the standard Expensify character limit error to the errorText prop of the TextInput:

function TextInputFilterComponents({filterKey, value, autoFocus, onChange}: TextInputFilterComponentsProps) {
    const {translate} = useLocalize();
    const styles = useThemeStyles();

    const label = translate(FILTER_VIEW_MAP[filterKey].labelKey);
    const {inputCallbackRef} = useAutoFocusInput();
    const textLength = value?.length ?? 0;
    const hasError = textLength > CONST.MAX_COMMENT_LENGTH;
    const errorText = hasError ? translate('common.error.characterLimitExceedCounter', textLength, CONST.MAX_COMMENT_LENGTH) : '';

    return (
        <TextInput
            ref={autoFocus ? (inputCallbackRef as (ref: BaseTextInputRef | null) => void) : undefined}
            placeholder={label}
            value={value}
            onChangeText={onChange}
            accessibilityLabel={label}
            role={CONST.ROLE.PRESENTATION}
            containerStyles={[styles.ph5]}
            errorText={errorText}
        />
    );
}

2. In src/components/Search/FilterComponents/AdvancedFilters/TextInputFilterContent.tsx:
   Update TextInputFilterContent to disable the "Confirm" button when the TextInput has an error, preventing the user from submitting a filter that exceeds the maximum length.

function TextInputFilterContent({filterKey, value: initialValue, autoFocus, largeButton, style, onChange}: TextInputFilterContentProps) {
    const {translate} = useLocalize();
    const styles = useThemeStyles();
    const [value, setValue] = useState(initialValue);
    
    const textLength = value?.length ?? 0;
    const hasError = textLength > CONST.MAX_COMMENT_LENGTH;

    return (
        <View style={[styles.flex1, styles.justifyContentBetween, style]}>
            <FilterComponents
                value={value}
                policyIDs={undefined}
                filterKey={filterKey}
                policyIDQuery={undefined}
                autoFocus={autoFocus}
                onChange={(v) => setValue(typeof v === 'string' ? v : undefined)}
            />
            <Button
                style={[styles.ph5, styles.pb5]}
                success
                large={largeButton}
                text={translate('common.confirm')}
                pressOnEnter
                onPress={() => onChange(value)}
                isDisabled={hasError}
            />
        </View>
    );
}

This ensures the user sees a clear, localized error message when the character limit is reached, and correctly disables submission.

What alternative solutions did you explore? (Optional)

We could enforce maxLength={CONST.MAX_COMMENT_LENGTH} directly on the TextInput. However, this would silently block the user from typing past the limit and fail to display the expected error message indicating why their input is blocked, violating the expected result detailed in the bug report. Using errorText and isDisabled provides a better UX and aligns with how Expensify handles length validation on other comment/input fields.

[Abdulloh0109]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 20:31:45 UTC.

Proposal

What is the root cause of that problem?

This is a gap in #94013 ("Add text-based filter length validation"), which merged on 2026-07-07, hours before this bug was filed.

That PR routes every text filter through the new useTextFilterValidation hook, which shows a "Character limit exceeded" error once the value's byte length exceeds a per-filter max. But FILTER_MAX_LENGTH only defines three keys — Description, Merchant, Title — and everything else falls through to CONST.MAX_COMMENT_LENGTH:

App/src/components/Search/hooks/useTextFilterValidation.tsx

Lines 11 to 21 in c08f57f

	const FILTER_MAX_LENGTH: Partial<Record<SearchTextFilterKeys, number>> = {
	[CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION]: CONST.DESCRIPTION_LIMIT,
	[CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT]: CONST.MERCHANT_NAME_MAX_BYTES,
	[CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE]: CONST.TASK_TITLE_CHARACTER_LIMIT,
	};
	function useTextFilterValidation(filterKey: SearchTextFilterKeys, value: string | undefined, onError?: (error: string | undefined) => void) {
	const {translate} = useLocalize();
	const maxLength = FILTER_MAX_LENGTH[filterKey] ?? CONST.MAX_COMMENT_LENGTH;
	const {isValid, byteLength} = isValidInputLength(value?.trim() ?? '', maxLength);
	const error = !isValid ? translate('common.error.characterLimitExceedCounter', byteLength, maxLength) : undefined;

MAX_COMMENT_LENGTH is 15000 — the chat-message limit, which has nothing to do with search filters:

App/src/CONST/index.ts

Line 5055 in c08f57f

MAX_COMMENT_LENGTH: 15000,

So Keyword and Report ID (neither is mapped) inherit a 15000-byte ceiling. The error only fires when the trimmed byte length is strictly greater than that — isValidInputLength treats anything <= maxLength as valid:

App/src/libs/ValidationUtils.ts

Lines 760 to 763 in c08f57f

	function isValidInputLength(inputValue: string, byteLength: number) {
	const valueByteLength = StringUtils.getUTF8ByteLength(inputValue);
	return {isValid: valueByteLength <= byteLength, byteLength: valueByteLength};
	}

The catch: 15000 bytes is never reachable inside the field. TextInputFilterContent passes no maxLength to lower that threshold, and the underlying input stops accepting text well before 15000 — the PR author flagged a native Android cap in the QA steps ("NOTE: Android natively has a max length of 5000"), and the reporter observed exactly this ("The app simply stops accepting additional text after a long input"):

App/src/components/Search/FilterComponents/AdvancedFilters/TextInputFilterContent.tsx

Lines 45 to 60 in c08f57f

	const error = useTextFilterValidation(filterKey, value);
	return (
	<View style={[styles.flex1, styles.justifyContentBetween, style]}>
	<TextInput
	ref={(ref) => {
	if (!autoFocus || !isTextInput(ref)) {
	return;
	}
	inputCallbackRef(ref);
	}}
	placeholder={label}
	value={value}
	errorText={error}
	hasError={!!error}
	onChangeText={setValue}

So the value can never exceed 15000, isValid stays true, and no error is ever shown. Merchant (255) and Description (1000) work because their limits sit far below what the input accepts, so those thresholds are reachable and their errors fire — which is also the proof that a ~1000 limit is reachable on the affected device.

Two more keys share this exact fallback and are silently broken the same way: Withdrawal ID, and every report-field text filter (the dynamic report-field-* keys, which route through the same hook via ReportFieldText). They can't be enumerated in FILTER_MAX_LENGTH, so they all collapse onto the unreachable 15000 default:

App/src/components/Search/types.ts

Lines 292 to 301 in c08f57f

	type SearchTextFilterKeys =
	| typeof CONST.SEARCH.SYNTAX_FILTER_KEYS.MERCHANT
	| typeof CONST.SEARCH.SYNTAX_FILTER_KEYS.DESCRIPTION
	| typeof CONST.SEARCH.SYNTAX_FILTER_KEYS.REPORT_ID
	| typeof CONST.SEARCH.SYNTAX_FILTER_KEYS.KEYWORD
	| typeof CONST.SEARCH.SYNTAX_FILTER_KEYS.TITLE
	| typeof CONST.SEARCH.SYNTAX_FILTER_KEYS.WITHDRAWAL_ID
	| typeof CONST.SEARCH.SYNTAX_ROOT_KEYS.LIMIT
	| ReportFieldTextKey;

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

Config layer, one line, in useTextFilterValidation: change the fallback from CONST.MAX_COMMENT_LENGTH to CONST.SEARCH_QUERY_LIMIT (keep the explicit Merchant/Description/Title entries as-is).

Why SEARCH_QUERY_LIMIT (1000) is the right, safe number rather than an invented one:

• It's the app's own existing ceiling for search query text — the main search bar already hard-caps the entire query at it via maxLength={CONST.SEARCH_QUERY_LIMIT} (SearchAutocompleteInput, SearchPageInput). A single filter value that feeds into that query should never be allowed to exceed the query itself, so this also removes an existing inconsistency.
• It's provably reachable on the affected platform: DESCRIPTION_LIMIT is the same 1000 and its error already shows correctly (here), so the fix can't reintroduce the "unreachable threshold" bug.
• It's generous — a report ID is a short numeric ID and a keyword search never needs 1000+ characters — so it won't produce false positives on realistic input.

Changing the fallback (rather than adding two explicit map entries) is deliberate: it fixes Keyword, Report ID, Withdrawal ID and the open-ended report-field-* text filters in one place. Adding only KEYWORD/REPORT_ID to FILTER_MAX_LENGTH would leave the report-field text filters still broken, since their keys are dynamic and can't be listed.

Regression to fix alongside it: the PR's own unit test pins Keyword to the old fallback and expects MAX_COMMENT_LENGTH — update it to expect SEARCH_QUERY_LIMIT (and/or point it at a genuinely unmapped key), otherwise it fails:

App/tests/unit/hooks/useTextFilterValidation.test.tsx

Lines 68 to 72 in c08f57f

	it('falls back to MAX_COMMENT_LENGTH for filters without a specific limit', () => {
	const length = CONST.MAX_COMMENT_LENGTH + 1;
	const value = 'x'.repeat(length);
	const {result} = renderValidationHook(CONST.SEARCH.SYNTAX_FILTER_KEYS.KEYWORD, value);
	expect(result.current).toBe(expectedError(length, CONST.MAX_COMMENT_LENGTH));

No offline/optimistic surface — this is pure client-side validation. The only edge case touched is the empty/whitespace value, which the hook already trims before measuring, and the numeric limit: filter, which is far too short to ever hit 1000.

What alternative solutions did you explore? (Optional)

Hard-cap the filter input with maxLength equal to the validation limit. Rejected — the app's pattern here is to let the value exceed the limit and then surface the characterLimitExceedCounter counter (that's precisely why Merchant/Description/Title pass no maxLength). Capping the input at the limit means it can never be exceeded, which suppresses the error for every text filter — reproducing this exact "no error" bug everywhere instead of fixing it.

Add explicit KEYWORD/REPORT_ID entries to FILTER_MAX_LENGTH and leave the fallback as MAX_COMMENT_LENGTH. Rejected as incomplete — it fixes the two reported fields but leaves Withdrawal ID and all report-field-* text filters (which can't be enumerated in the static map) still validating against the unreachable 15000. Fixing the fallback covers the whole family with less code.

Suspecting Keyword/Report ID were never wired into the hook. Refuted by the code: SearchTextFilterKeys explicitly lists REPORT_ID and KEYWORD, isTextFilterKey routes them into TextInputFilterContent/TextFilterPopup, and the hook runs for them every keystroke. The hook fires fine — its error just never becomes truthy because the threshold is out of reach. So the defect is the limit value, not the wiring.