[2.0 / next] Reading a pending getter in equals leaves the UI stuck
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 14/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript, typescript
- Domain
- frontend
Research direction
Start in packages/signals/src/core/core.ts around the synchronous comparator catch, and in packages/signals/src/core/async.ts around the async settlement catch and the shared handleError path. Both catches call notifyStatus(el, STATUS_ERROR, e) on NotReadyError, so pending reads are treated as terminal. Reproduce with the linked pending-getter playground, then check the cleanup regression in PR #3886. Done means the getter reaches Value: 2 and the cleanup test passes, which needs maintainer input on how suspension inside equals should behave.
Written by the indexing model from the issue text.
Description
Describe the bug
A memo returns an object with a getter that reads an async memo. Reading the getter during rendering works with <Loading>, but reading it in equals produces an uncaught NotReadyError. The async work then resolves, yet the UI stays on the previous value.
Removing the custom comparator lets the same getter render the resolved value.
Your Example Website or App
https://s.olid.uk/id/-g2RtrPeRk-xTEPedugSCg
Steps to Reproduce the Bug or Issue
- Open the playground and wait for
Value: 0. - Click Run demo. The comparator reads the new object's getter while its async memo is unresolved. The console reports
NotReadyError. - After one second, the console logs
Resolved: 2, but the UI remains atValue: 0.
Control: remove the equals option and rebuild. Repeat the steps: the UI reaches Value: 2 without the error.
Expected behavior
A pending read through the getter should be handled by <Loading> and allow the UI to reach Value: 2 once the async work resolves. If reads that suspend are unsupported inside equals, a clear diagnostic would be preferable to an uncaught control-flow error that leaves updates halted.
Screenshots or Videos
No response
Platform
- OS: Linux
- Browser: Chromium 154.0.8037.57
- Solid: playground pinned to
next@d5e32a9af41c7bfe0bc090f7438ee4297d540b17. The comparator catches discussed below are also present on currentnext@ccd99481deed3ebb567ee11ab7a152ced84d122b.
Additional context
The comparator catches in synchronous recomputation and async settlement both unconditionally call notifyStatus(el, STATUS_ERROR, e). That appears to classify a pending read as a terminal error. Comparator reads also run outside the memo's tracking context, so classifying NotReadyError as pending alone would not establish the dependency needed to retry.
The async catch additionally bypasses the existing shared error handler, which handles promise rejections and errors from the async setter. A candidate change from #3886 is:
} catch (e) {
- notifyStatus(el, STATUS_ERROR, e);
+ handleError(e);
}
That change fixes a separate cleanup omission: if a lazy dependent loses its last consumer while the async source is pending, and the source's comparator throws on fulfillment, the dependent is left subscribed and its cleanup never runs. Cleanup playground: click Run demo and inspect Cleanup calls: 0; ordinary fulfillment and direct promise rejection each produce 1 in the same setup. The memo's owner stays alive; only its rendered consumer is removed.
Routing the async catch through handleError makes that cleanup regression pass, along with the existing comparator-error and pending-disposal tests. Non-lazy cleanup still waits for owner disposal in the tested case. However, this change alone does not make the pending-getter example recover: the async version instead reports an untracked-read diagnostic. The synchronous comparator catch and the intended handling of suspension inside comparators need consideration too.
#3886 contains the candidate async-handler change and cleanup regressions. That comparator-release case was outside #4085's held-error scope.
- Dominant language
- TypeScript
- Stars
- 36.1k
- Forks
- 1.1k
- Avg merge
- 11h 32m
- Merged PRs (30d)
- 356
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from solidjs/solid
-
Difficulty 4/5 3-5 days Newbie friendliness 22/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 18/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 22/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 15/100
Maintainers usually reply within 1 day
Similar issues
-
documentation good first issue
Difficulty 2/5 Half a day Newbie friendliness 72/100
sujithputta02/Esapay#13 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
ehmpathy/rhachet-roles-bhuild#468 ·
Maintainers usually reply within 1 day
-
Share dialog: the address book's contact count reads "1 contacts" (no singular form in any language)Possibly taken @chibenwa claimed this today. Openai-driven-qa bug claude Cosmetic
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
linagora/twake-contacts-frontend#271 · 1 comment ·
Maintainers usually reply within 1 day
-
factory-active task-identify-harness-labels-done task-identify-issue-type-done
Difficulty 1/5 Under an hour Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Koenkk/zigbee2mqtt#33402 ·
Maintainers usually reply within 1 day