BINDING_SLOT_POSITION
Binding-slot value where it cannot bind; data.reason names the position (spread is an error and throws), client reasons orphan/fill-shape.
What you saw
- Kind:
ssr,render - Severity:
warn(code that works but is structurally wrong or expensive) orerror(broken behavior)
The console report opens with [BINDING_SLOT_POSITION] and the message, then an in line naming the owners that enclose the subject, root first, and an at line with the source location when the code was compiled with one.
In a captured artifact the same finding is an event with code: "BINDING_SLOT_POSITION", ownerPath, and loc.
Diagnostics explains each line.
Why it fires
A binding slot's property (const row = props.row(args); row.done) landed where the server template cannot bind it.
The server runtime reports on the same channel, with the same in <App> › <Page> line.
Two groups.
Findings (SSR_RENDER_ERROR_CONTAINED, SSR_SUBTREE_ABANDONED, SSR_STREAM_ABANDONED, LATE_HEADER_WRITE, DYNAMIC_ASYNC_COMPONENT, SERVER_ERROR_SANITIZED, FRAME_MARKER_CORRUPTED) are facts about a render that exist in observe builds too — an APM sees them in production; in dev they print.
Checks (the rest, SSR_BOUNDARY_WATERFALL and SSR_CLIENT_CONTENT_MASKED included) are dev-only guidance.
A captured artifact from a server render carries both.
How to fix it
The rule: a slot property is a JSX attribute value, whole, and nothing else.
data.reason: "spread" (throws — the slot's whole return spread onto an element; name each position instead), "stringified" (coerced into a string — a template literal, a concatenation), "coerced" (used in an expression — a comparison, arithmetic, a branch on its result; the server has no value to compute with, so decide in the client fill and return the decided value), "inline" (reached class/style inside template quotes — the element was compiled without the serverComponents compiler option), "text" (placed as text, not a bindable position yet), "markup" (read off a slot whose client fill returned content, not an object), "server-local" (a ref/on* position got a plain server function — bind a slot property or an action=), "tuple" (an on* position got an array — return the [handler, data] tuple from the fill instead), "reserved-key" (the fill's object used a key the slot's range occupies), "orphan" (client, kind render: an element carries markers for an occurrence that can never bind — data.why "fill", no client fill for the prop; "record", a called occurrence with no args record once none can arrive, which is the protocol out of step — client and server from different builds — not a fill mistake).
For stringified/coerced/inline/text NOTHING renders at the position on either face, so the misuse shows on the first render, not the first refetch.
Truthiness (if (row.done)) has no hook and is the one misuse only the rule catches — a stand-in is always truthy.
The fuller guide is @solidjs/web's skills/server-components/SKILL.md.
In tests
captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw.
expectNoDiagnostics(artifact) fails while BINDING_SLOT_POSITION is among them, with the events as evidence; after the fix, the code is gone from artifact.diagnostics.
Check for regressions in tests shows the loop and the Vitest matcher form.
Learn more
- Diagnostics: every code, with its kind, severity, and trigger.
- Debugging reactivity: how to read a report and what each group of codes points at.