Page MenuHomePhabricator

[web] Fix message search results for old query appearing
ClosedPublic

Authored by inka on Jun 27 2023, 6:36 AM.
Tags
None
Referenced Files
F3241136: D8327.diff
Wed, Nov 13, 3:05 PM
Unknown Object (File)
Sat, Nov 9, 4:04 AM
Unknown Object (File)
Fri, Nov 8, 6:38 AM
Unknown Object (File)
Thu, Nov 7, 1:18 AM
Unknown Object (File)
Oct 15 2024, 1:24 AM
Unknown Object (File)
Oct 2 2024, 9:25 AM
Unknown Object (File)
Oct 2 2024, 9:25 AM
Unknown Object (File)
Oct 2 2024, 9:25 AM
Subscribers

Details

Summary

If the user searched for "first query", and then before the results had the chance to appear, search for "second query", the results for "first query" would still be appended to the results array.
This diff fixes that by using an id for each server call, and after the results get fetched, the id of the server call is compared with the most recent id.

Test Plan

Checked that flow is not broken in web and native that both use useSearchMessages. checked that the above scenario doesn't happen anymore (I used network dev tools to ensure the messages didn't get fetched before the query was changed). Checked that it is still possible to fetch messages, and more messages for the same query.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

inka edited the test plan for this revision. (Show Details)
inka requested review of this revision.Jun 27 2023, 6:57 AM
web/search/message-search-state-provider.react.js
117 ↗(On Diff #28164)
127 ↗(On Diff #28164)

I'm confused about this line. Shouldn't we wait until the most recent query completes before setting this? It appears we are letting eg. query 4 set loading to false before query 5 completes

lib/shared/search-utils.js
233 ↗(On Diff #28164)

Why is this parameter optional? Is there any callsite that doesn't pass it in? If you want to allow undefined / null, it would be better to make the parameter required, but have it take ?number

236 ↗(On Diff #28164)

Same feedback as above

web/search/message-search-state-provider.react.js
124 ↗(On Diff #28164)

Same feedback as above

Instead of using another variable, could we pass query to appendResults and check if it's still the same?

queryID was optional in useSearchMessages, because useSearchMessages is used on native which didn't use the queryID, but it actually should

Instead of using another variable, could we pass query to appendResults and check if it's still the same?

No, because someone might:

  • query for 'a', wait to see results (server call no 1), scroll down and start fetching the second page of results for 'a' (server call no 2)
  • query for 'b' (server call no 3)
  • query for 'a' (server call no 4)

then they would see results for server call 2, so the second page of the results for 'a', instead of the first page

This revision is now accepted and ready to land.Jun 30 2023, 5:37 AM