fix(ui): Fix occasional stale cash when adding/removing multiple data products#16743
Conversation
|
Linear: CAT-1607 |
|
✅ Meticulous spotted 0 visual differences across 1526 screens tested: view results. Meticulous evaluated ~9 hours of user flows against your PR. Expected differences? Click here. Last updated for commit cda32eb. This comment will update as new commits are pushed. |
Bundle ReportChanges will increase total bundle size by 514 bytes (0.0%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: datahub-react-web-esmAssets Changed:
Files in
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Since data products are associated with assets only through the
relationshipsquery (which goes through elastic) if you add or remove multiple data products, you're not just updating one aspect, but one for each affected data product. Therefore if you add a few products or one at a time remove multiple, when we refetch after each removal or refetch after the bulk adds, sometimes the data products you get back after that refetch are incorrect, and then get cached that way if you were to go to search results and look at the sidebar and come back.This PR makes a change where we intentionally bypass the cache for an entity profile data fetch the next time we need it. This is much more reliable than a 3 second hardcoded wait and refetch, because this will simply do a real refetch next time we need it, instead of just hoping it's ready after 3 seconds.
Additionally, with a 3 second wait if a user leaves the page before those 3 seconds are up then the refetch never happens and we are stuck with the previously cached data which does not include the mutation, and we show stale data. Now we always fetch fresh for the given entity the next time we need it.
It's still possible of course if a user leaves really quickly and gets to a spot where we refetch that elastic isn't updated, but that is simply the risk of eventual consistency and reliance on elastic, not much we can do here right now.
I think this approach will be nice for all entity profile mutations that require a 3 second wait and refetch. More efficient and more reliable.