• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

solidjs / solid / 41121878578
78%
main: 89%

Build:
Build:
LAST BUILD BRANCH: claude/project-thread-x1ore2-floor-savings
DEFAULT BRANCH: main
Ran 30 Oct 2026 08:25PM UTC
Jobs 1
Files 12
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

30 Oct 2026 08:16PM UTC coverage: 78.1%. Remained the same
41121878578

push

github

web-flow
fix(signals): every answer resolved in the tick a write re-asks it rides the write's flush (#4495) (#4499)

* fix(signals): a first answer landing in the tick a write re-asks it is answered, then re-asked (D-22, F-9)

An async memo's first answer resolves, and in the same synchronous turn a
plain write re-asks it; the promise reaction runs after the write, so the
landing and the re-ask are processed in one flush. The runtime treated the
answer as never produced:

- `asyncWrite` dropped it outright when the write's notification had marked
  the node dirty (a stale-answer guard meant for re-asks).
- Otherwise it landed staged, the re-ask left the node pending and
  uninitialized, and `isPending` gave it no verdict (`false` from the
  flush's probe, never re-run), while an identity memo or a derived store
  over it never derived from it (`latest` of either threw: [ROOT-L]).

Now a first answer always lands; `isPending` of a node answered and
re-asked in one flush is the re-ask's verdict (true); and a memo with no
value of its own that reads it derives from the answer once, then re-runs
on the missed-wake latch and waits on the re-ask holding it (a verdict
engine hook, so the hello-world floor pays only the call). Amends D-22's
2026-10-28 clause per the 2026-10-30 ruling: a plain write re-asking the
memo carries the answer like an action's.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2

* fix(signals): a first answer landing in the tick a write re-asks it is answered, then re-asked (D-22, F-9)

An async memo's first answer resolves, and in the same synchronous turn a
plain write re-asks it; the promise reaction runs after the write, so the
landing and the re-ask are processed in one flush. The runtime treated the
answer as never produced:

- `asyncWrite` dropped it outright when the write's notification had marked
  the node dirty (a stale-answer guard meant for re-asks).
-... (continued)

790 of 1090 branches covered (72.48%)

Branch coverage included in aggregate %.

1125 of 1362 relevant lines covered (82.6%)

29.81 hits per line

Jobs
ID Job ID Ran Files Coverage
1 41121878578.1 30 Oct 2026 08:25PM UTC 12
78.1
GitHub Action Run
Source Files on build 41121878578
  • Tree
  • List 12
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #41121878578
  • ef0aadd8 on github
  • Prev Build on next (#41118267371)
  • Next Build on next (#41121884398)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc