Skip to content

Fix: New expense not visible in grouped-by from search when created offline#92132

Open
aswin-s wants to merge 19 commits into
Expensify:mainfrom
aswin-s:fix/issue-91453
Open

Fix: New expense not visible in grouped-by from search when created offline#92132
aswin-s wants to merge 19 commits into
Expensify:mainfrom
aswin-s:fix/issue-91453

Conversation

@aswin-s

@aswin-s aswin-s commented May 30, 2026

Copy link
Copy Markdown
Contributor

Explanation of Change

When a user created an expense offline from anywhere other than the currently-active search view (e.g. from an Aswin S chat), the new expense was missing from already-loaded from:<me> filter and Group By: From snapshots.

Root cause: getSearchOnyxUpdate only wrote optimistic data into the snapshot of the currently active search query (getCurrentSearchQueryJSON().hash). Any other loaded snapshot whose query the new transaction would satisfy never received the optimistic write.

Fix:

  1. Allow from:<currentUser> as the sole flat filter to pass shouldOptimisticallyUpdateSearch (new matchesFromQuery branch).
  2. Persist each loaded search's query string under a new SEARCH_QUERY_BY_HASH Onyx key from getOnyxLoadingData (a dedicated key, because the SEARCH API response wipes anything stored on snapshot.search).
  3. Refactor getSearchOnyxUpdate around a writeForQuery helper that iterates the hash→query map and fans the optimistic write to every snapshot whose stored query still matches the new transaction. For groupBy:from matches, also write the group_<fromAccountID> entry and pre-populate the per-member transactions snapshot.
  4. Mirror the snapshot collection's lifecycle in the IOU module-level subscription so SEARCH_QUERY_BY_HASH entries are evicted when their snapshot disappears, keeping the map bounded.

Fixed Issues

$ #91453
PROPOSAL: #91453 (comment)

Tests

  1. Open New Expensify web app and sign in.
  2. Go to Spend > Expenses.
  3. Apply Filter > From > yourself via the UI — note the visible list.
  4. Open Display > Group By > From so its snapshot is loaded. Note your own group's count and total.
  5. Disable your network connection (DevTools → Network → Offline or Troubleshoot → Force offline).
  6. Open Inbox > another user (e.g. mr.aswin@gmail.com) and create a new expense (manual, any amount).
  7. Without going online, navigate to Spend > Expenses → the new expense appears at the top.
  8. Apply Filter > From > yourself → the new expense is visible.
  9. Open Display > Group By > From → your group row's count is +1 and total is incremented by the new amount.
  10. Go back online → values reconcile with server data and the expense remains visible.
  • Verify that no errors appear in the JS console

Offline tests

  1. Follow steps 5–9 of the Tests section above — the entire scenario is offline.
  2. Verify the optimistic write reaches both the from:<me> filter and the group-by:from snapshots even though the expense was created from a chat.
  3. Verify the optimistic group row count/total increment correctly when a group row already existed for your account.

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."

  1. Open staging.new.expensify.com and sign in.
  2. Visit Spend > Expenses, apply Filter > From: me via the UI, then Display > Group By > From so both snapshots are loaded.
  3. Note your group row's count and total.
  4. Go offline (DevTools → Network → Offline).
  5. From a chat with another user, create a new expense (any amount).
  6. Verify the new expense appears in Spend > Expenses (unfiltered), in Filter > From: me, and that Group By > From shows your row updated (count +1, total += new amount).
  7. Go back online → verify the row reconciles with server data.
  • Verify that no errors appear in the JS console

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for the expected offline behavior in the Offline steps section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
    • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • Android: Native
    • Android: mWeb Chrome
    • iOS: Native
    • iOS: mWeb Safari
    • MacOS: Chrome / Safari
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
    • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
  • I verified that if a function's arguments changed that all usages have also been updated correctly
  • If any new file was added I verified that:
    • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
  • If new assets were added or existing ones were modified, I verified that:
    • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
    • The assets load correctly across all supported platforms.
  • If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
  • If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
    • I verified that all the inputs inside a form are aligned with each other.
    • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
  • If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
  • I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
android-native.mp4
Android: mWeb Chrome
android-web.mp4
iOS: Native
ios-native.mp4
iOS: mWeb Safari
ios-web.mp4
MacOS: Chrome / Safari
Web.mp4

aswin-s added 2 commits May 30, 2026 08:51
…ting expense offline

When the search view has groupBy:from active, creating an expense offline
did not write a group_<fromAccountID> entry into optimisticSnapshotData.
getMemberSections renders exclusively from group_-prefixed Onyx keys, so
the new expense was invisible until the next online sync.
The initial fix always computed count:1 and total:transaction.amount
because optimisticSnapshotData is a fresh object per call. Subscribe to
the SNAPSHOT collection at module level so the existing group_ entry can
be read and its count/total incremented correctly. Also preserve the
existing group's currency rather than overwriting it.
@aswin-s aswin-s changed the title [] Fix: New expense not visible in grouped-by-From search when created offline Fix: New expense not visible in grouped-by-From search when created offline May 30, 2026
@aswin-s aswin-s changed the title Fix: New expense not visible in grouped-by-From search when created offline Fix: New expense not visible in grouped-by from search when created offline May 30, 2026
aswin-s added 8 commits June 2, 2026 16:57
- Narrow group key template literal with 'as const' to satisfy PrefixedRecord index type
- Optional-chain allSnapshots access since OnyxCollection may be undefined
- Bump eslint-seatbelt baseline for new module-level Onyx.connect
Co-locate the snapshot Onyx subscription with the existing IOU module-level getters (allTransactions, allReports, etc.) and expose it via getAllSnapshots(). Avoids introducing a new seatbelt-baselined file; the existing IOU/index.ts no-onyx-connect count ticks from 10 to 11.
…User>

shouldOptimisticallyUpdateSearch previously gated the optimistic write on hasNoFlatFilters or one of the canned Submit/Approve/UnapprovedCash queries. A flat search with from:me as the only filter matched none of those, so an offline-created expense never reached the from-filtered snapshot. Add matchesFromQuery so the user's own from-filter passes the gate.
…e new transaction

getSearchOnyxUpdate only wrote to the currently active search's snapshot, so an
offline expense created from a chat never reached the from:<me> filter or the
groupBy:from view loaded in another tab/route. Persist each loaded search's
query string under a new SEARCH_QUERY_BY_HASH Onyx key (the SEARCH API response
wipes anything stored on snapshot.search), then iterate that map and apply the
optimistic write to every snapshot whose query still matches via
shouldOptimisticallyUpdateSearch.
Mirror the snapshot collection's lifecycle in the IOU module-level subscription:
diff the previous vs current hash set on each callback and merge nulls for
hashes that were removed. This bounds SEARCH_QUERY_BY_HASH to the size of the
loaded snapshot collection.
- Search.ts: clarify the SEARCH_QUERY_BY_HASH side effect with a more explicit comment
- IOU/index.ts: use String.slice instead of String.replace for hash extraction
- IOU/index.ts: build the eviction payload with an explicit Record<string, string | null>
  to make the deletion-via-null intent type-visible
- SearchUpdate.ts: rename groupTransactionsQuery -> groupTransactionsQueryJSON to match
  the file's existing JSON-suffix naming convention
@codecov

codecov Bot commented Jun 2, 2026

Copy link
Copy Markdown

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines Coverage Δ
src/ONYXKEYS.ts 100.00% <ø> (ø)
src/libs/actions/IOU/index.ts 100.00% <100.00%> (ø)
src/libs/actions/Search.ts 38.80% <100.00%> (+0.24%) ⬆️
src/libs/actions/IOU/SearchUpdate.ts 87.03% <85.18%> (-5.07%) ⬇️
... and 10 files with indirect coverage changes

aswin-s added 2 commits June 3, 2026 02:34
…x.ts

The fanout in SearchUpdate.ts depends on subscribing to SEARCH_QUERY_BY_HASH
at module level (same pattern used by the existing snapshot subscription),
which is the 12th Onyx.connect violation in this file. Bumping the baseline
from 11 to 12 via SEATBELT_INCREASE keeps the existing grandfathered count
visible while letting this PR pass CI.
Adds two minimal tests for the refactored guard at the top of
getSearchOnyxUpdate: returns undefined when participant has no accountID,
and when there is no current user account. Closes part of the patch
coverage gap from Expensify#92132 without dragging in fan-out path mocking.
@aswin-s aswin-s marked this pull request as ready for review June 2, 2026 21:22
@aswin-s aswin-s requested review from a team as code owners June 2, 2026 21:22
@melvin-bot melvin-bot Bot requested review from eVoloshchak and flaviadefaria and removed request for a team June 2, 2026 21:22
@melvin-bot

melvin-bot Bot commented Jun 2, 2026

Copy link
Copy Markdown

@eVoloshchak Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

@melvin-bot melvin-bot Bot requested review from a team and mjasikowski and removed request for a team June 2, 2026 21:22
@melvin-bot

melvin-bot Bot commented Jun 2, 2026

Copy link
Copy Markdown

@mjasikowski Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6c8b543049

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread src/libs/actions/IOU/index.ts
@eVoloshchak

Copy link
Copy Markdown
Contributor

@aswin-s, this isn't the approach described in the accepted proposal, was there a problem with the original approach?

@aswin-s

aswin-s commented Jun 8, 2026

Copy link
Copy Markdown
Contributor Author

@aswin-s, this isn't the approach described in the accepted proposal, was there a problem with the original approach?

@eVoloshchak — yes, the original approach was correct in principle: I added the group_ entry into optimisticSnapshotData inside the groupBy === FROM branch exactly as proposed. That first commit fixed the grouped view.

However, while implementing it I noticed the issue title and reproduction video were actually showing two distinct but related cases:
• The issue description referred to Display → Group by: From view
• The attached video demonstrated the Filter → From → me flat-filter view

Both were broken for the same underlying reason (no optimistic write reaching those snapshots), so I had to addressed both.

aswin-s added 4 commits June 9, 2026 18:29
All group types in the SearchResultDataType union (SearchMemberGroup,
SearchCardGroup, SearchCategoryGroup, etc.) share count, total, and
currency properties, so narrowing to SearchMemberGroup was unsafe and
unnecessary.
@aswin-s

aswin-s commented Jun 19, 2026

Copy link
Copy Markdown
Contributor Author

@eVoloshchak Could you take another look at this PR?

@eVoloshchak

Copy link
Copy Markdown
Contributor

Apologies, I'm a bit late
@aswin-s, could you pull the latest main please?

Screenshot 2026-06-22 at 19 18 56

@aswin-s

aswin-s commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

@eVoloshchak Merged latest main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants