[Due for payment 2026-06-11] [$250] View payment history from:me is being passed to the backend literally

[trjExpensify]

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.89-5
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A
Email or phone of affected tester (no customers): In thread.
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: @johncschuster
Slack conversation (hyperlinked to channel name): #product

Action Performed:

1. Have an account with billing history
2. Go to Account > Subscription > View payment history

Expected Result:

User should see all their billing receipts when navigated to the Spend page.

Actual Result:

User lands on "No results".

Workaround:

Yes, use the filters in the Spend page manually to create the same search.

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

In thread.

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061574196232260468
• Upwork Job ID: 2061574196232260468
• Last Price Increase: 2026-06-01

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

"View payment history" navigates directly to the Spend/Search page with a query that contains the literal keyword from:me, and nothing resolves me into the current user's accountID on that navigation path — so from:me is sent to the backend verbatim and matches nothing → "No results".

The me → accountID substitution only runs when a query is submitted through the search input box (getQueryWithSubstitutions), not when code navigates straight to the search route.

Evidence (code trace)

1. The button builds the query with the literal me keyword:
   src/pages/settings/Subscription/CardSection/CardSection.tsx:113 → from: [CONST.SEARCH.ME] (CONST.SEARCH.ME === 'me'). This produces the query string ... from:me and navigates directly to ROUTES.SEARCH_ROOT.

2. The only place me is converted to the current accountID is getQueryWithSubstitutions.ts:71, which is only called from the search input (SearchRouter.tsx:262) and useSearchPageInput. Direct navigation to SEARCH_ROOT never hits it.

3. The pre-backend value transform getUpdatedFilterValue (SearchQueryUtils.ts:408-419) only substitutes emails → accountIDs for from. For me it does getPersonalDetailByEmail('me') which returns undefined, so it falls back to the literal 'me'.

4. The other place that resolves me (SearchQueryUtils.ts:1151) is buildFilterFormValuesFromQuery — the reverse path that populates the filter form, not the query that is sent to the backend. (This is why the manual-filter workaround works: picking yourself stores your real accountID.)

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

In CardSection.tsx:113, pass the current user's accountID instead of the me keyword. The component already reads session via useOnyx(ONYXKEYS.SESSION), so use from: [String(session?.accountID)].

This matches the established pattern for code that programmatically navigates to search (which uses the real accountID, not me), e.g. YourSpendSection/queries.ts:18 and ForYouSection/index.tsx.

What alternative solutions did you explore? (Optional)

Resolve the me keyword centrally so any direct navigation to SEARCH_ROOT is safe — e.g. handle me for user filter keys inside getUpdatedFilterValue (which is part of the search-execution path). This is more robust but broader in scope; given the established accountID convention for programmatic navigation, the targeted CardSection fix is preferred.

Possibly related: #89402 ("View payment history" scoping to the billing owner) — the from:me filter appears to have been added for that scoping, which introduced this bug.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

Clicking "View payment history" under Account > Subscription navigates the user to the Spend search page, but the resulting search returns "No results" even when the account has billing history. The cause is that the literal string me is being sent to the backend as the value of the from: filter, instead of being resolved to the current user's account ID.

What is the root cause of that problem?

The viewPurchases handler in CardSection.tsx builds a search query via buildQueryStringFromFilterFormValues, hard-coding from: [CONST.SEARCH.ME] (where CONST.SEARCH.ME === 'me'). It then navigates directly to ROUTES.SEARCH_ROOT with that query string:

App/src/pages/settings/Subscription/CardSection/CardSection.tsx

Lines 100 to 117 in 4ffea53

	const viewPurchases = () => {
	const query = buildQueryStringFromFilterFormValues({
	type: CONST.SEARCH.DATA_TYPES.EXPENSE,
	status: [
	CONST.SEARCH.STATUS.EXPENSE.UNREPORTED,
	CONST.SEARCH.STATUS.EXPENSE.DRAFTS,
	CONST.SEARCH.STATUS.EXPENSE.OUTSTANDING,
	CONST.SEARCH.STATUS.EXPENSE.APPROVED,
	CONST.SEARCH.STATUS.EXPENSE.DONE,
	CONST.SEARCH.STATUS.EXPENSE.PAID,
	CONST.SEARCH.STATUS.EXPENSE.DELETED,
	],
	merchant: CONST.EXPENSIFY_MERCHANT,
	from: [CONST.SEARCH.ME],
	});
	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query}));
	};

from: [CONST.SEARCH.ME],
// produces "from:me" in the URL, which is sent verbatim to the backend

The "me → accountID" resolution is not performed by buildQueryStringFromFilterFormValues, nor by the search page on load. The only code that resolves me lives in getQueryWithSubstitutions, which is invoked exclusively from the SearchRouter input flows (SearchRouter.submitSearch and useSearchPageInput) — i.e. only when a user types/edits a query in the search bar. Direct programmatic navigation bypasses that path entirely:

App/src/components/Search/SearchRouter/getQueryWithSubstitutions.ts

Lines 70 to 73 in 4ffea53

	// Resolve the 'me' keyword to the current user's account ID when not in the substitution map
	if (!substitutionEntry && range.value === CONST.SEARCH.ME && USER_FILTER_KEYS.has(range.key) && currentUserAccountID && currentUserAccountID > 0) {
	substitutionEntry = currentUserAccountID.toString();
	}

So when SearchQueryProvider parses the URL q param it stores from: "me" unchanged in the SearchQueryJSON, and actions/Search.search() serializes that JSON to the backend via serializeQueryJSONForBackend. The backend treats me as a literal filter value (it expects a numeric account ID or email), matches nothing, and returns an empty result set. There is downstream me → accountID resolution inside buildFilterFormValuesFromQuery for the advanced filters form (line 1151 of SearchQueryUtils.ts), but that is for rebuilding the form UI from a URL — it never modifies the query that actually reaches the API. The codebase confirms the expected pattern: src/pages/home/YourSpendSection/queries.ts (lines 18, 27, 36) consistently builds from: [String(accountID)] after reading accountID via useCurrentUserPersonalDetails, which is exactly what CardSection's call site is missing.

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

Fix the bug at the call site in viewPurchases by passing the current user's resolved numeric account ID instead of the literal me token. The session is already subscribed in this component at line 56 (const [session] = useOnyx(ONYXKEYS.SESSION)), so we can use session?.accountID and guard against the (rare) case where it is unavailable. This matches the canonical pattern used by YourSpendSection/queries.ts and keeps the change local — no shared utility needs to be touched, no other callers are at risk of regressing:

App/src/pages/home/YourSpendSection/queries.ts

Lines 14 to 21 in 4ffea53

	function buildAwaitingApprovalQuery(accountID: number): string {
	return buildQueryStringFromFilterFormValues({
	type: CONST.SEARCH.DATA_TYPES.EXPENSE,
	status: CONST.SEARCH.STATUS.EXPENSE.OUTSTANDING,
	from: [String(accountID)],
	reimbursable: CONST.SEARCH.BOOLEAN.YES,
	});
	}

const viewPurchases = () => {
    if (!session?.accountID) {
        return;
    }
    const query = buildQueryStringFromFilterFormValues({
        type: CONST.SEARCH.DATA_TYPES.EXPENSE,
        status: [/* …unchanged… */],
        merchant: CONST.EXPENSIFY_MERCHANT,
        from: [String(session.accountID)],
    });
    Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query}));
};

This produces from:<numericAccountID> in the URL, which the backend resolves correctly, and the receipts for Expensify, Inc. will load. Because CardSection.tsx is the only production caller that passes CONST.SEARCH.ME into buildQueryStringFromFilterFormValues, no other flow is impacted. The fix is also safe for the search-bar UX: when the user later edits the query in the search input, the existing display logic in SearchQueryUtils.getDisplayValue (lines 1461-1464) will format the numeric accountID back to the me token for the current user, so the chip in the search bar still shows "me" as expected.

What alternative solutions did you explore? (Optional)

We considered teaching buildQueryStringFromFilterFormValues itself to substitute me with the current user's account ID before serializing the from/to/assignee/etc. filters. Rejected because that helper is a pure synchronous string builder used in 30+ sites (including tests that assert exact output) and has no access to currentUserAccountID; threading it through would require touching every caller. The localized fix in CardSection.tsx is the lowest-risk change and matches the established pattern in YourSpendSection/queries.ts.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-01 22:31:28 UTC.

Proposal

What is the root cause of that problem?

viewPurchases() in src/pages/settings/Subscription/CardSection/CardSection.tsx builds the payment-history canned search with from: [CONST.SEARCH.ME], then passes that same query as both query and rawQuery:

App/src/pages/settings/Subscription/CardSection/CardSection.tsx

Lines 100 to 116 in 4ffea53

	const viewPurchases = () => {
	const query = buildQueryStringFromFilterFormValues({
	type: CONST.SEARCH.DATA_TYPES.EXPENSE,
	status: [
	CONST.SEARCH.STATUS.EXPENSE.UNREPORTED,
	CONST.SEARCH.STATUS.EXPENSE.DRAFTS,
	CONST.SEARCH.STATUS.EXPENSE.OUTSTANDING,
	CONST.SEARCH.STATUS.EXPENSE.APPROVED,
	CONST.SEARCH.STATUS.EXPENSE.DONE,
	CONST.SEARCH.STATUS.EXPENSE.PAID,
	CONST.SEARCH.STATUS.EXPENSE.DELETED,
	],
	merchant: CONST.EXPENSIFY_MERCHANT,
	from: [CONST.SEARCH.ME],
	});
	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query}));

Search then parses the canonical q and the optional rawQuery into currentSearchQueryJSON:

App/src/components/Search/SearchQueryProvider.tsx

Lines 33 to 36 in 4ffea53

	const queryParam = useRootNavigationState((state) => selectSearchQueryParam(state ?? navigation.getState()));
	const rawQueryParam = useRootNavigationState((state) => selectSearchRawQueryParam(state ?? navigation.getState()));
	const definedQueryParam = usePreviousDefined(queryParam) ?? buildSearchQueryString();
	const currentSearchQueryJSON = buildSearchQueryJSON(definedQueryParam, rawQueryParam);

That query is sent through search(), which serializes it for the Search API:

App/src/hooks/useSearchPageSetup.ts

Lines 71 to 72 in 4ffea53

	const shouldSkipWaitForWrites = hasDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH);
	search({queryJSON, searchKey: currentSearchKey, offset: 0, shouldCalculateTotals, isLoading: false, skipWaitForWrites: shouldSkipWaitForWrites});

App/src/libs/actions/Search.ts

Lines 547 to 558 in 4ffea53

	const {optimisticData, finallyData, failureData} = getOnyxLoadingData(queryJSON.hash, queryJSON, offset, isOffline, true, shouldCalculateTotals);
	const {flatFilters, limit, ...queryJSONWithoutFlatFilters} = queryJSON;
	const query = {
	...queryJSONWithoutFlatFilters,
	searchKey,
	offset,
	filters: queryJSONWithoutFlatFilters.filters ?? null,
	shouldCalculateTotals,
	// Backend expects 'maximumResults' instead of 'limit'
	...(limit !== undefined && {maximumResults: limit}),
	};
	const jsonQuery = serializeQueryJSONForBackend(query);

serializeQueryJSONForBackend() only normalizes merchant/description operators. It does not replace user aliases like me, so the backend can receive from = "me" literally and return no billing receipts:

App/src/libs/SearchQueryUtils.ts

Lines 2164 to 2174 in 4ffea53

	function serializeQueryJSONForBackend<T extends {filters?: ASTNode | null; rawFilterList?: RawQueryFilter[]}>(queryData: T): string {
	const normalizedFilters = queryData.filters ? applyContainsOperatorToTextFields(queryData.filters) : queryData.filters;
	const normalizedRawFilterList = queryData.rawFilterList
	? queryData.rawFilterList.map((filter) => {
	if (TEXT_SEARCH_FIELDS.has(filter.key) && filter.operator === CONST.SEARCH.SYNTAX_OPERATORS.EQUAL_TO) {
	return {...filter, operator: CONST.SEARCH.SYNTAX_OPERATORS.CONTAINS};
	}
	return filter;
	})
	: queryData.rawFilterList;
	return JSON.stringify({...queryData, filters: normalizedFilters, rawFilterList: normalizedRawFilterList});

This does not need from:me in the route for display. Search already renders the current user's numeric account ID as me in user-friendly query text:

App/src/libs/SearchQueryUtils.ts

Lines 1456 to 1464 in 4ffea53

	filterName === CONST.SEARCH.SYNTAX_FILTER_KEYS.ASSIGNEE ||
	filterName === CONST.SEARCH.SYNTAX_FILTER_KEYS.PAYER ||
	filterName === CONST.SEARCH.SYNTAX_FILTER_KEYS.EXPORTER ||
	filterName === CONST.SEARCH.SYNTAX_FILTER_KEYS.ATTENDEE
	) {
	if (filterValue === CONST.SEARCH.ME) {
	return CONST.SEARCH.ME;
	}
	return filterValue === currentUserAccountID.toString() ? CONST.SEARCH.ME : getDisplayNameOrDefault(personalDetails?.[filterValue], filterValue, false);

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

Update viewPurchases() so the canned payment-history query uses the current user's account ID from the existing session subscription instead of CONST.SEARCH.ME.

Concretely, build the from filter with String(session.accountID) when the account ID is available, and pass a backend-safe query into ROUTES.SEARCH_ROOT.getRoute(). Do not pass a rawQuery that still contains from:me; either omit rawQuery or pass the same account-ID query there as well.

Add focused regression coverage for the payment-history query/route. It should prove the route contains the intended expense statuses, merchant:"Expensify, Inc.", and from:<currentAccountID>, and that neither q nor rawQuery contains from:me.

Scope boundaries: this should only touch src/pages/settings/Subscription/CardSection/CardSection.tsx and focused tests. It affects all platforms that use the shared subscription page/search route. It should not change the Search parser, autocomplete substitution, advanced filter form hydration, manual user-entered from:me searches, Search API contracts, or backend behavior.

What alternative solutions did you explore? (Optional)

I considered teaching serializeQueryJSONForBackend() to resolve me, but that serializer is shared by Search, CSV/export, and bulk-action flows and currently has no current-user account context. That would be a broader cross-cutting change for a bug caused by one canned navigation source.

I also considered changing only canonical q while leaving rawQuery=from:me, but rawQuery is parsed into rawFilterList and included in the serialized backend payload. For this canned route, both query representations should be backend-safe.

[aswin-s]

Proposal

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

On Web (MacOS Chrome/Safari), when a user with billing history navigates to Account → Subscription → View payment history, they land on a Spend page that shows "No results" instead of their billing receipts. Expected: the Spend page should be pre-filtered to the user's Expensify-merchant purchases and display them.

What is the root cause of that problem?

In src/pages/settings/Subscription/CardSection/CardSection.tsx:100-117, viewPurchases() builds the search query with from: [CONST.SEARCH.ME] and navigates directly to ROUTES.SEARCH_ROOT. buildQueryStringFromFilterFormValues serializes this verbatim as from:me (see src/libs/SearchQueryUtils.ts:930-963, the FROM array branch just joins sanitized values) and does not substitute the me token with the current user's accountID. The me→accountID resolution only happens in the SearchRouter typing/substitution flow (getQueryWithSubstitutions) and in the reverse parser path (SearchQueryUtils.ts:1151); since this navigation skips the SearchRouter, the literal string me reaches the backend as the from filter value, which matches no accountID and yields "No results".

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

1. In src/pages/settings/Subscription/CardSection/CardSection.tsx:100-117, replace from: [CONST.SEARCH.ME] with the current user's accountID using the already-available session?.accountID (read at line 56), e.g. from: session?.accountID ? [session.accountID.toString()] : []. This produces from:<accountID> in the URL, which the backend can resolve correctly and which the reverse parser at line 1151 will also map back to the user when rendering the filter chip.
2. Guard against the missing-session edge case: if session?.accountID is unavailable, omit the from filter entirely rather than emitting an empty value that could short-circuit the search.
3. Add a brief comment near the call site explaining why accountID is used in place of CONST.SEARCH.ME here — direct navigation bypasses SearchRouter substitution.

What alternative solutions did you explore? (Optional)

Centralize the substitution inside buildQueryStringFromFilterFormValues so any CONST.SEARCH.ME token in from/to/assignee/exporter arrays is resolved to the current user's accountID at build-time. Rejected as the wider blast radius: many SearchRouter call sites intentionally produce me (so the chip stays "Me" after navigation/parse round-trips), and changing serialization there could break saved-search hash stability — the targeted fix at the one direct-navigation caller is safer.

[melvin-bot]

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

[melvin-bot]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.