Exceptions during database upgrade no longer closes the connection

[stelar7]

After #458, the condition for closing with an error was changed to check the requests error.
Unfortunately that will never be true, as we pass that point before the request has its error set.

Following the flow, it seems to go like this:
open -> upgrade -> queue TASK A -> wait for finished state -> close if request's error is set
TASK A -> upgrade needed -> did throw = true -> abort -> transaction set as finished -> queue TASK B
TASK B -> request gets its error set.

Since the transaction gets marked as finished before TASK B is started (we will finish TASK A with TASK B still pending), upgrade will then check if the transaction is finished, (which it is at this point), go back to open, where step 10.8 will not see the error yet.

Possible idea for solution:

• New step after 5. in abort: If transaction is an upgrade transaction: Set transaction's associated request's error to a newly created "AbortError" DOMException.

[SteveBeckerMSFT]

Good find! For the potential solution, what is the transaction's associated request? Since transaction's have a request list, we'd probably need to set the error for each request in the list?

At this point, maybe we've proven that your original idea to return the upgrade transaction and then check its error might be cleanest and best? Sorry for the churn. Thanks for iterating!

[stelar7]

what is the transaction's associated request?

its the open request associated with transaction.
Its mentioned a few times in the spec[1], but i dont think there is any steps that set it 🤔

In LB, we set it during upgrade 10.2, then clear it in abort 7.3.2 and commit 2.5.4

[1] aborting a transaction 7.3.1 and committing a transaction 2.5.4