IndexedDB 2.0: Queue up completed requests in the client, handle them one by one Note: Currently we only send one operation to the server at a time, so therefore we only ever have one reply in the client at a time. But with the patch in https://bugs.webkit.org/show_bug.cgi?id=164932 that will change, and a subtle race is introduced in event handling on the client side. To resolve that, we'll need this refactor.
Created attachment 295329 [details] Patch for EWS (not quite for review) Giving EWS a shot before hitting the sack, hopefully this'll be ready for review tomorrow.
Created attachment 295349 [details] Patch
Comment on attachment 295349 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=295349&action=review > Source/WebCore/Modules/indexeddb/IDBTransaction.cpp:265 > + m_currentlyCompletingRequest = nullptr; This seems unnecessary
(In reply to comment #3) > Comment on attachment 295349 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=295349&action=review > > > Source/WebCore/Modules/indexeddb/IDBTransaction.cpp:265 > > + m_currentlyCompletingRequest = nullptr; > > This seems unnecessary It keeps an assertion valid as we walk the tight loop of things to abort.
The problems that the EWS bots were seeing on transaction-scheduler-6 were due to a bug in the test. Fixing that now and giving EWS another pass.
Created attachment 295497 [details] Patch
Created attachment 295584 [details] Patch
Hammered the tests locally with and without this patch, along with a fix for the test that EWS originally had a problem with. Things seem to be good now. Will let EWS re-run on it before I cq+
Comment on attachment 295584 [details] Patch Clearing flags on attachment: 295584 Committed r209069: <http://trac.webkit.org/changeset/209069>
All reviewed patches have been landed. Closing bug.