Bug 70041 - IndexedDB: Transactions fail to abort if all requests throw exceptions
Summary: IndexedDB: Transactions fail to abort if all requests throw exceptions
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Joshua Bell
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-13 12:10 PDT by Joshua Bell
Modified: 2011-11-16 11:37 PST (History)
4 users (show)

See Also:


Attachments
Repro case for the bug (1.05 KB, text/html)
2011-10-13 12:13 PDT, Joshua Bell
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Bell 2011-10-13 12:10:27 PDT
Repro:

* Start a transaction
* Make a request against the transaction that raises an exception (e.g. a put() with an invalid key)
* Make no other requests against the transaction, let it execute

Expected:

* Transaction fires abort event

Actual:

* Transaction never fires abort, error or complete events

Initial investigation:

This appears to be caused by the path taken when requests are created but aborted early due to exceptions - a request is created, registered with the transaction, then marked for "early death". But the markEarlyDeath() method does not unregister it from the transaction; that doesn't happen until the request's destructor is called. Perhaps it should be unregistered immediately? Further investigation is needed, and we should understand why the transaction never completes.
Comment 1 Joshua Bell 2011-10-13 12:13:21 PDT
Created attachment 110885 [details]
Repro case for the bug

Attachment (bug70041.html) should show ABORTED (or ERROR or COMPLETE) but never does.

You can try commenting out both store.put() to see it output ABORTED, or uncomment both store.put() calls to see it COMPLETE
Comment 2 Joshua Bell 2011-10-13 12:32:21 PDT
NOTE: LayoutTests/storage/indexeddb/objectstore-basics.html has an unexpected dependency on this buggy behavior - it creates a transaction that has no requests other than one which generated an exception, yet expects the transaction to not abort. So fixing this issue may cause that layout test to (erroneously) fail.
Comment 3 Joshua Bell 2011-11-03 16:23:58 PDT
The attached repro case no longer repros :( It reports "ABORTED"
Comment 4 Joshua Bell 2011-11-09 11:29:40 PST
(In reply to comment #3)
> The attached repro case no longer repros :( It reports "ABORTED"

To clarify, it repros in M16, but not TOT Chrome.