Home - Recently added expenses change after reset app

[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.17-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: #93451
Email or phone of affected tester (no customers): jsoidjnsoijoisjidsoj2@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create 3 expenses in DM with user.
• Create 3 expenses in workspace cha

1. Go to staging.new.expensify.com
2. Go to Account > Troubleshoot > Clear cache and restart > Reset and refresh.
3. Go to Home.
4. Open the first expense (not the latest five expenses) in Recently added section.
5. Close the RHP.

Expected Result:

After reset app, Recently added section will show the latest five expenses.

Actual Result:

After reset app, Recently added section shows the first expense. It disappears after opening the expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188074_1782170671188.6.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7188074

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[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/1209b4b676415858a93294724a54aaa6dc4d33955862465421079a9a0fa4ca52

[melvin-bot]

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

[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

Root Cause: The "Recently added" slot orders expenses by their inserted (insertion) timestamp, but that timestamp is not in the Search snapshot the slot reads from — it only exists in the local transactions_ Onyx collection for recently-added expenses. "Reset and refresh" wipes transactions_ (it isn't in the KEYS_TO_PRESERVE list), so on a cold cache every row falls back to the expense date in getRecencyKey (… ?? transaction.inserted ?? getCreated(transaction) ?? ''). The list is therefore ordered by expense date / stable snapshot order instead of insertion order, surfacing an old expense at the top. Opening an expense rehydrates transactions_ with inserted, which re-sorts the list — exactly why the stale row "disappears after opening."

The complete fix requires a backend change, outside the App repo. Because inserted is genuinely unavailable on the client after a cache reset, the only way to order correctly on a cold cache is for the Search command to include each transaction's inserted timestamp in the EXPENSE snapshot (Auth / Web-Expensify). Once the snapshot carries inserted, the hook's existing transaction.inserted fallback works with no dependency on the local collection. This should be escalated to an internal engineer with access to the Search backend (file under Expensify/Expensify).

Deploy-blocker stopgap (App-side): If a backend change can't land in time, the safe option is to feature-flag / revert the slot rather than ship known-wrong ordering. A pure App-side loading gate (using searchResults.search.isLoading) only hides the flicker — once loading finishes, transactions_ is still empty, so the date-based mis-order still shows. It does not fix the symptom.

Investigation details & evidence

• Why only an old expense shows at top: with no inserted available, all rows tie on the recency key (expense date, or ''), so the stable sort preserves raw snapshot/object-iteration order — which puts the first-created expense on top.
• transactions_ and SNAPSHOT are both wiped on reset: "Reset and refresh" → clearOnyxAndResetApp() → Onyx.clear; neither collection is preserved.
• inserted is only written on the optimistic create path (TransactionUtils:447) and is an optional field. No OpenApp/ReconnectApp response repopulates it, so after reset it's absent until the user re-creates or opens an expense.
• The snapshot can't be sorted into insertion order client-side either: there is no inserted sort column in CONST.SEARCH.TABLE_COLUMNS, and the snapshot stores data as a keyed record iterated via Object.entries, so backend order isn't preserved.
• Hook comments already flag the limitation: useRecentlyAddedData.ts:70-72.
• Open backend question: does the Search index already track inserted per transaction (small change to expose it) or not (larger change)? Needs an Auth/Web-Expensify investigation.

Introduced by #93451 (the slot's PR). Confidence: High (deterministic code-path issue, fully explained by static analysis).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94237) — note the App-side portion is only the feature-flag/revert stopgap; the real fix is backend.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's analysis.