-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: Onyx.cleanCache
#81
Fix: Onyx.cleanCache
#81
Conversation
`OnyxCache.remove` was renamed to `drop` and updated so that it does not remove the `key` but only the value This way the result of `getAllKeys` is unaffected Related to Expensify#76
When we remove values from storage we cache that the value was removed from storage The next time someone requests this value we can tell them right away it's null and they don't need to wait to read this from storage
You might be concerned that cache will never remove values from Lines 373 to 382 in 9b03d95
I don't think it's a problem as Lines 389 to 399 in 9b03d95
An alternative is to add another |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tests well and the regression is solved, thanks for the quick fix!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of comments. Overall I agree that this is a bug:
on disconnect it tells cache to remove the iou from cache - because there are no more usages on screen
but cache.remove would also remove it from the storageKeys (the bug)
But less sure why we are calling cache.set('someKey', null)
in the two places we are.
// Remove from cache | ||
cache.remove(key); | ||
// Cache the fact that the value was removed | ||
cache.set(key, null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsure why we need to do this. 🤔
@@ -639,7 +639,7 @@ function clear() { | |||
.then((keys) => { | |||
_.each(keys, (key) => { | |||
keyChanged(key, null); | |||
cache.remove(key); | |||
cache.set(key, null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gonna merge this so we can unbreak the production release, but still curious about the cache.set()
stuff. I don't think anything bad can happen from it just not sure I understand it.
When we remove something using You can also verify this is the way AsyncStorage works by default for a missing key await AsyncStorage.removeItem('myItem');
const value = await AsyncStorage.getItem('myItem'); // `null` We're skipping the call to |
Cool thanks, I get that part, I just don't see how it is related to the linked issue or regression and someone looking at the code might not understand the purpose. Reaching into storage is how we treat most other "gets" for a key that does not exist in Onyx so it's not clear why we are making an exception here or whether it makes any difference. |
comment could be improved as it doesn't explain why we are doing this |
Well now instead of reaching for storage we know ahead of time that the key is not there - when something deliberately removed a key using Previously (actually still is for some cases) this was achieved by using As you can see we no longer remove keys for the result of Lines 373 to 382 in 9b03d95
I've tried to explain this here: #81 (comment) If you want to also remove the key from the result of Just like we can cache the fact that we have something, we can do the same to cache that we know there's no value in storage for a given key - and skip the call to storage |
I'll try being more direct here:
Can you elaborate (in the code) so that others (not me) in the future can understand what your intentions were? |
Every change here is related to the issue
My intentions are explained here and in the git log. The code for remove and clear explains itself I don't think people reading the code in the feature would be confused that remove(key) is doing cache.set(key, null) - it's pretty clear what that means If you need me to do something specific, add different comments or change the code like I've suggested as alternative I can do it tomorrow, but otherwise I don't know see what can I do |
|
Are you sure? The issue you're talking about was discovered before this PR was even merged - "iOS - App crashes after turning off the internet connection" - the code you're quoting wasn't included in the app at that time And the update that bumps E.cash to use the Onyx changes made here happened even later that day: Expensify/App#3483 Check the timing of this comment and the time of the merges - https://expensify.slack.com/archives/C01GTK53T8Q/p1623256929142800 |
Ah yes sorry you are 100% right. I've got the wrong PR. More grandly, it's a change from this diff between the versions of react-native-onyx as seen here: https://github.com/Expensify/react-native-onyx/compare/d0a5d12c08f2f029e3038fb3516a93a9403e9746..52c254fbc4b96224d2ac087e57ef6efc4210ccc1 (This is comparing the production react-native-onyx in production with what's on staging/master). This just happened to be the most recent onyx change so I thought it was from here, but it's a little tricky to pinpoint the exact PR. I'll put more details in the Cash issue I got this from. |
@Julesssss @marcaaron
Details
Renamed
Cache.remove
toCache.drop
this method should not remove the key fromgetAllKeys
's resultUpdated
Onyx.remove
andOnyx.clear
theyset
the cached value tonull
this waythe next connection does not have to wait to read
null
from storageRelated Issues
#76 (comment)
Expensify/App#3482
Automated Tests
Updated the tests for
cache.drop
Linked PRs