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

solidjs / solid / 40452237597
79%
main: 89%

Build:
Build:
LAST BUILD BRANCH: claude/project-thread-x1ore2-4375
DEFAULT BRANCH: main
Ran 27 Oct 2026 05:00AM 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

27 Oct 2026 04:53AM UTC coverage: 78.589%. Remained the same
40452237597

push

github

web-flow
fix(solid,web): a failed Errored waits for its fallback's async holes before streaming (#4308)

* fix(solid,web): draw an Errored fallback for a Loading's async failure, and adopt it (#4287)

Outside a server component, a <Loading> whose async read failed during a
streamed render settled its fragment blank, and the hydrating client
rendered the failed boundary from scratch: it asked again and showed the
loading fallback.

Server: the failing <Loading> now asks the enclosing <Errored> for its
outcome outside server components too, passing its own id. The Errored
answers only when that Loading is all of its content (its resolved markup
is the Loading's placeholder): its fallback is drawn into the fragment, or
inlined pre-flush, and the error is serialized at the Errored id. Deeper
in the content it answers nothing, as before. A rejected fragment's
template is marked `e`, and `$dfr` records the nodes it swaps in for it.

Client: inside a hydrated Errored's no-claim content run, a <Loading>
runs its content with its data adopted instead of waiting on its
fragment, so the Errored holds the client's own error and tracks the
content's inputs (#4273). A boundary that claimed its fallback and then
renders a rejected fragment fresh clears the nodes the swap put in first,
so nothing of the server's outcome is left beside the client's render.

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

* fix(solid): serialize an Errored's error only when its fallback markup is sent

When a streamed <Loading> fails after the shell and asks the enclosing
<Errored> for its outcome, the fallback may hold an async hole that has
not resolved yet. renderOutcome then returns no markup (the fragment
settles as a plain rejection), but handleError had already serialized
the error at the Errored id. A client hydrating after the failure read
that record, claimed a fallback that was never sent, a... (continued)

785 of 1074 branches covered (73.09%)

Branch coverage included in aggregate %.

1120 of 1350 relevant lines covered (82.96%)

28.11 hits per line

Jobs
ID Job ID Ran Files Coverage
1 40452237597.1 27 Oct 2026 05:00AM UTC 12
78.59
GitHub Action Run
Source Files on build 40452237597
  • 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 #40452237597
  • 542ff6f5 on github
  • Prev Build on next (#40418049278)
  • Next Build on next (#40452227969)
  • 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