ambient: Fix potential Settings timing issue
Currently in Settings page, the request settings and update settings calls are independently, which could make local cache |settings_| out of sync of server side. Two potential timing issues are: 1. Call UpdateSettings(), and immediately call RequestSettingsAndAlbums(). It is possible that RequestSettingsAndAlbums() reads stale settings on server earlier than the server is updated. When RequestSettingsAndAlbums() returns, it will overwrite local |settings_| with old value, but the server got updated with new value. 2. Vice versa, call RequestSettingsAndAlbums(), and then immediately call UpdateSettings(). RequestSettingsAndAlbums() returns with old value and overwrite local |settings_| with old value. For example: 1. On album selection page (ambientMode/photos page), user makes changes to select different albums. It will change local cache |settings_| to the selected albums list. And call update settings to server. 2. Immediately, user goes back to ambientMode page, current code will trigger requesting settings from server. 3. It is not guarantee that update settings will update server before request settings, so if request settings succeeds earlier, it will return stale data and overwrite local |settings_|. The major changes in this patch: 1. When request settings, if there is ongoing UpdateSettings(), we do not call RequestSettingsAndAlbums(). We update the UI when UpdateSettings() returns. 2. When update settings, if there is ongoing RequestSettingsAndAlbums(), we invalidate the weakPtr to prevent changing local settings, and call UpdateSettings(). 3. If UpdateSettings() fails, will update UI with previous settings data. Bug: b/169448409 Test: Added new unittests Change-Id: Icfc156fba22087b6b438464d7ac9a711a31a390c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2458951Reviewed-by:Jimmy Gong <jimmyxgong@chromium.org> Reviewed-by:
Xiaohui Chen <xiaohuic@chromium.org> Commit-Queue: Tao Wu <wutao@chromium.org> Cr-Commit-Position: refs/heads/master@{#816789}
Showing
This diff is collapsed.
Please register or sign in to comment