mirror of
https://github.com/LadybirdBrowser/ladybird
synced 2026-05-03 13:02:09 +02:00
If one request on a transaction succeeds, then the next one fails, that would cause the abort algorithm to run before the success for the first request due to the task queue ordering. Instead, queue the processing for the next request after the completion of the current request.
17 lines
902 B
Plaintext
17 lines
902 B
Plaintext
Harness status: OK
|
|
|
|
Found 12 tests
|
|
|
|
12 Pass
|
|
Pass Explicitly committed data can be read back out.
|
|
Pass commit() on a version change transaction does not cause errors.
|
|
Pass A committed transaction becomes inactive immediately.
|
|
Pass A committed transaction is inactive in future request callbacks.
|
|
Pass Puts issued after commit are not fulfilled.
|
|
Pass Calling commit on an aborted transaction throws.
|
|
Pass Calling commit on a committed transaction throws.
|
|
Pass Calling abort on a committed transaction throws and does not prevent persisting the data.
|
|
Pass Calling txn.commit() when txn is inactive should throw.
|
|
Pass Transactions with same scope should stay in program order, even if one calls commit.
|
|
Pass Transactions that explicitly commit and have errors should abort.
|
|
Pass Transactions that handle all errors properly should behave as expected when an explicit commit is called in an onerror handler. |