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

solidjs / solid / 40846126698
78%
main: 89%

Build:
Build:
LAST BUILD BRANCH: next
DEFAULT BRANCH: main
Ran 29 Oct 2026 09:06AM 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

29 Oct 2026 08:59AM UTC coverage: 78.516%. Remained the same
40846126698

push

github

web-flow
fix(signals): an async memo over a verdict memo asks each question once (#4397)

* fix(signals): an async memo over a verdict memo asks each question once

A memo that reads a verdict memo is a verdict reader (F-6, #4050), and
propagateStatus re-derived every verdict reader when its source went
pending. Re-derived, an async one was served the committed value it had
already derived from (A10) and asked that question again; that flight
held the verdict lane, and the source's held landing re-ran it as lane
work onto the same committed value, a third ask. Only the landing's
re-derive asked the new question.

Now an async memo that is a verdict reader only by reading a verdict
memo (it opened no isPending/latest window of its own: REACTIVE_WINDOW,
set per pass by markVerdictReader) drops CONFIG_VERDICT when that memo
goes pending and takes the plain pending mark: it is pending through the
flight (F-9) and the hold's work until it lands, reading plainly (D-25,
#3884), and asks once at the landing. Sync readers re-derive as before.

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

* fix(signals): an async memo with no verdict window of its own takes no verdict role

#4397 review: with two verdict sources (`m1 = ask(1 + m0() + m0b())` over
`m0 = ask(1 + latest(s) + s())` and `m0b = ask(10 * (latest(t) + t()))`),
the grouped `[isPending(m1), m1()]` reader asked `m1:5` a second time on
stale inputs after both sources landed. m1 lost CONFIG_VERDICT when its
first source went pending, but a pass that threw NotReady at that
source's read picked it back up (F-6, `read`). The settle walk then
re-ran m1 as a verdict reader, and the committed values a hold had moved
past were served to it (A10).

The demotion is now per pass, in `recompute`. An async memo (new
CONFIG_ASYNC: its last answering pass registered a flight) whose pass
opened no isPending/latest window of its own (REACTIVE_WINDOW... (continued)

790 of 1084 branches covered (72.88%)

Branch coverage included in aggregate %.

1125 of 1355 relevant lines covered (83.03%)

29.93 hits per line

Jobs
ID Job ID Ran Files Coverage
1 40846126698.1 29 Oct 2026 09:06AM UTC 12
78.52
GitHub Action Run
Source Files on build 40846126698
  • 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 #40846126698
  • f94dcd59 on github
  • Prev Build on next (#40843737053)
  • Next Build on next (#40855047438)
  • 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