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]
Comment on attachment 295349 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=295349&action=review
> + m_currentlyCompletingRequest = nullptr;
This seems unnecessary
(In reply to comment #3)
> Comment on attachment 295349 [details]
> View in context:
> > 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]
Created attachment 295584 [details]
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]
Clearing flags on attachment: 295584
Committed r209069: <http://trac.webkit.org/changeset/209069>
All reviewed patches have been landed. Closing bug.