The Indexed DB spec (and, from testing, other implementations) work something like this:

1. Wait for this request's turn.
2. Do some magical back-end operations to compute result.
3. Queue a task to run these steps:
    1. Set request's result to result.
    2. Set request's readyState to 'done'.
    3. Fire a 'success' event at request.

Blink's implementation works like this:

1. Wait for this request's turn.
2. Do some magical back-end operations to compute result.
3. Queue a task to run these steps:
    1. Set request's result to result.
    2. Set request's readyState to 'done'.
    3. Queue a task to fire a 'success' event at request.

This is observable as racy behavior where the change to request's state is observable before the event fires, either through polling or e.g. when a failed upgrade's 'abort' is queued then the 'error' is queued. Depending on when the queue is processed, the request's state may have changed before or after the 'abort' is actually dispatched.

We already special case this for cursors, in that a cursor's state doesn't change until the event is dispatched: 

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/indexeddb/IDBRequest.cpp?l=454

Now that we're introducing overall response queuing to handle large value wrapping maybe can fix and simplify here.