fix: don't override new current_batch#18170
Conversation
This is a regression from #18117 - we moved `this.#commit()` higher up but that means that `current_batch` could be nulled out / overridden through `batch.activate/deactivate` / blocker runs inside `#commit()`. Therefore restore the previous value afterwards. No changest because #18117 is not released yet.
|
|
|
So here's something rather odd: the test passes, but it doesn't work in the playground (or locally, in the sandbox). I can't for the life of me figure out why. |
…tch if there's a pending boundary
|
Nice find! Turns out the logic in #18131 was also flawed, because it is a false positive in the test case in the playground:
|
|
Tried to leave a review comment but github is so completely broken that it doesn't work, so I guess I'll just leave a screenshot of a review comment instead? We all need to move off this joke of a platform yesterday 
|
Fixes a regression of #18170 (not released yet therefore no changeset). `current_batch` is nulled out if the `#commit` rebases other branches, and that can lead to nullpointers down the line. No test right now but it's part of getting the failing SvelteKit test passing.
This is a regression from #18117 - we moved
this.#commit()higher up but that means thatcurrent_batchcould be nulled out / overridden throughbatch.activate/deactivate/ blocker runs inside#commit(). Therefore restore the previous value afterwards. No changest because #18117 is not released yet.Fixes the other part of the failing SvelteKit
query.livetest.