1 Commits (c894afd8c73e4f08a377909f29aa58177a256277)

Author	SHA1	Message	Date
Nic Polumeyv	2b740e496e	fix: commit a reaction's dependencies even when it throws (#18703) ... Fixes #18414 and a second bug with the same cause. `update_reaction` in `runtime.js` commits a reaction's dependencies after `fn()` returns: it swaps in `new_deps`, removes stale reactions and registers the reaction into each new dep's `reactions`. When `fn()` throws, the whole block is skipped. Two things go wrong from that. A derived that the run read for the first time was already set `CONNECTED` in `get` and registered itself into its own deps' `reactions` during `update_derived`, but the throwing reaction never registers as its reader. It sits in its deps' `reactions` with `reactions === null` of its own, `remove_reaction`'s disconnect cascade can never reach it, and it retains its `ctx`, closures and DOM past component destruction and `unmount()`. A derived that throws during its own run ends up with no dependencies at all. It is not in its sources' `reactions`, so a later change to them never re-runs it, and for an unowned derived `update_derived` then marks the error value CLEAN because the derived has no deps. Anything reading it keeps getting the first error forever. The commit block is now `update_dependencies` and the `catch` calls it before `handle_error`, so a failing reaction keeps the deps it read up to the throw. That subscribes it to the inputs that produced the error, and lets the normal disconnect cascade clean up when it is destroyed (`Boundary.#handle_error` destroys the failed effect). Co-authored-by: Randy Murphy <randalmurphal@users.noreply.github.com>	4 days ago