[CP Staging] Revert "fix: stop Search re-firing an identical query on unrelated Onyx updates" - #98548
Conversation
|
@mkhutornyi @QichenZhu One of you needs to 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[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 79be2d8d3e
ℹ️ 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".
|
|
||
| // Check if there is a change in the transactions or report actions list | ||
| if ((isChat ? hasReportActionsIDsChange : hasTransactionsIDsChange) || hasPendingSearchRef.current) { | ||
| if ((!isChat && hasTransactionsIDsChange) || hasReportActionsIDsChange || hasPendingSearchRef.current) { |
There was a problem hiding this comment.
For a non-chat search this condition still enters when hasReportActionsIDsChange is true. The Search screen subscribes to the global report-actions collection and passes it into this hook (src/components/Search/index.tsx:170, src/components/Search/index.tsx:234-244), so sending or receiving any new chat action while an expense search page is open re-runs the current expense search even though no transaction changed; because newIDs below is the transaction key list, the later filter cannot recognize the report action as irrelevant. Keep report-action changes inside the chat branch.
Useful? React with 👍 / 👎.
| } | ||
| } | ||
|
|
||
| const newIDs = isChat ? reportActionsIDs : transactionsIDs; |
There was a problem hiding this comment.
In the non-chat branch transactionsIDs are Onyx collection keys from ONYXKEYS.COLLECTION.TRANSACTION (for example transactions_123), while extractTransactionIDsFromSearchResults() returns bare transactionID values (for example 123). Comparing these at line 125 makes every existing local transaction look absent from the results, so adding a transaction that is already in the snapshot—or keeping any filtered-out transaction in Onyx—bypasses the “no genuinely new ID” skip and re-fires an identical query. Build newIDs from transaction.transactionID for added/current transactions instead.
Useful? React with 👍 / 👎.
|
🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here. |
…re-highlight-hook [CP Staging] Revert "fix: stop Search re-firing an identical query on unrelated Onyx updates" (cherry picked from commit 08f4b61) (cherry-picked to staging by mountiny)
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
🚀 Cherry-picked to staging by https://github.com/mountiny in version: 9.4.53-2 🚀
|
Help site review: no changes requiredI reviewed the changes in this PR and no updates to Expensify's help site ( Why: This PR reverts #98305 and only touches internal implementation:
There is no change to any user-facing feature, UI label, tab, setting, button, or workflow that the help site documents. The Search feature's behavior from a user's perspective is unchanged — this is purely about the internal condition under which the query re-fires. Since no |
4 participants
Reverts #98305
Fixed issues
$ #98494
$ #98502
$ #98543
$ #98544