[IndexedDB] Fixed invalid max_object_store_id after database deletion
The connection request system keeps around the LevelDBDatabase object when a delete happens to allow subsequent open on that same database. To do this, it resets the IndexedDBMetadata back to a default state. During a recent refactor, this state reset wasn't done properly, and we don't have any tests to catch that error. This change fixes that incorrect state reset. A test isn't included here because: 1. It passes the third party test provided to us, 2. The current unittesting framework isn't great and needs to be replaced (don't want to create negative work) 3. It is pretty obvious this fixes the problem, and there are no other 'incorrectly' or 'not' re-initialized state here, 4. Current layout tests should have caught this, and it is unclear why. Bug to create this test: https://crbug.com/1018444 5. IndexedDB work is currently on the backburner while Storage Service is pursued, and won't be re-prioritized until next year-ish. I don't want to spend time on this now when it's needed for Storage Service work. If more P0 bugs crop up in IndexedDB over the next week, then we may have to re-think this policy and divert engineering effort towards making IndexedDB more stable. This is present in m78, which was just promoted to stable. If there are any more issues, we expect them to show up in the next week or so. TESTED=Manually tested using example test case from field. R=cmp@chromium.org Bug: 1018406 Change-Id: I36e42777e07ef91bf8cf11b9a633a9171ca3755e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1880320 Commit-Queue: Daniel Murphy <dmurph@chromium.org> Reviewed-by:Chase Phillips <cmp@chromium.org> Cr-Commit-Position: refs/heads/master@{#709702}
Showing
Please register or sign in to comment