fix(signals): settle resolve() when the async source rejects

[brenelz]

Summary

Fixes #2842 — resolve(fn) hung forever (never resolved, never rejected) and leaked its internal createRoot whenever the awaited async source rejected after having been pending. Resolution worked; rejection did not.

Root cause

resolve() was built on a bare computed inside a root, and computeds are pull-based. The two settlement paths are asymmetric:

• When a pending source resolves, settlePendingSource() explicitly re-enqueues blocked dependents, so the computed re-ran, called res(fn()), and disposed the root.
• When a pending source rejects, handleAsync's error path only propagates STATUS_ERROR through notifyStatus(), which marks subscribers errored for their next pull but never re-runs them. Nothing ever reads resolve()'s computed (it has no subscribers), so neither res nor rej fired and dispose() never ran.

Fix

Rebuild resolve() on a user effect — the primitive that owns an error-notification channel (_notifyStatus → _errorFn) and is therefore actively told when a pending source rejects:

• effect callback → res(value) + dispose (same observable timing as before)
• error callback → rej(err) + dispose, unwrapping the internal StatusError wrapper so the promise rejects with the user's original error, matching what createErrorBoundary exposes

Also documents the rejection behavior in the JSDoc.

Tests

New tests/resolve.test.ts pins the settlement contract:

• rejects with the original error when the async source rejects after pending (hung before this fix)
• disposes the internal root on rejection (hung before this fix)
• still resolves with the settled value on success
• rejects on a synchronous throw

Full solid-signals suite (814 tests) and solid suite (418 tests) pass.

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 59d5291

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codspeed-hq]

Merging this PR will not alter performance

✅ 120 untouched benchmarks

---

_{Comparing brenelz:fix/resolve-async-rejection (59d5291) with next (e2ebc11)}

[ryansolid]

Root cause is exactly right, and the asymmetry framing is the valuable part: settlePendingSource re-enqueues blocked dependents on resolution, but a rejection only propagates STATUS_ERROR through notifyStatus — which marks a pull-based computed errored for a pull that, with no subscribers, never comes. resolve()'s bare computed was exactly that shape, so the promise hung and the root leaked.

Rebuilding on a user effect is the right fix — the effect's error-notification channel (_notifyStatus → _errorFn) is the primitive that's actively told about rejections, and unwrapping the StatusError so the caller gets their original error matches what error boundaries expose. Verified the hang on the current tree, confirmed the full monorepo suite passes with your diff, and landed it as-is with a changeset, credited as co-author: c4ba5268. Ships in the next beta — thanks for another precise one.