Every state-subscription hook in core/react/ seeded local React state from
its store prop and re-synced it inside a useEffect. That shape paints one
frame of the previous store's data when the prop changes (switching
servers), and loses any event dispatched between the render that took the
snapshot and the effect that attached the listener.
Convert all 16 to useSyncExternalStore through a new shared
useStoreSnapshot, following useManagedListError (#1954).
useSyncExternalStore needs a referentially stable snapshot, and these
getters hand back a defensive copy, so TypedEventTarget now keeps a
per-event-type dispatch counter (getEventRevision) that the snapshot is
cached against. A contents comparison would not do: MessageLogState folds
a response into its request entry by mutating that entry in place, which a
shallow compare reports as unchanged. The bump lives on the dispatchEvent
override so no dispatch — including a hand-rolled CustomEvent — can bypass
it.
useInspectorClient is included though the issue did not list it; its nine
subscribed slices made the stale frame most visible. Its lastError stays
useState (accumulated from events, no getter to read back) but resets on
client swap during render rather than in an effect.
The settings-draft and async fetch hooks are deliberately untouched: the
former hold genuinely local editable state, the latter are I/O rather than
store subscriptions.
Also answers the issue's open question. react-hooks/set-state-in-effect
never fired here because eslint-plugin-react-hooks has never linted
core/react/ at all — it is a clients/web devDependency and the root config
loads no React plugin. Corrected the config comment that gave "no JSX" as
the reason; the gap itself is #2192, measured at 15 findings, none of them
in the hooks converted here.
Closes#1955
Signed-off-by: cliffhall <cliff@futurescale.com>
* feat(web): render pending sampling/elicitation requests (#1407)
Server-initiated sampling and elicitation requests never reached the v2
web UI: the InspectorClient queued them and returned a Promise that only
resolved on a user response, but nothing subscribed to the pending-change
events or rendered the (already-built) request components. A tool that
triggered one spun the Execute button forever.
Wire the queues to the UI:
- Add usePendingClientRequests() (core/react) subscribing to
pendingSamplesChange / pendingElicitationsChange and returning the live
arrays. Expose getPendingSamples() / getPendingElicitations() on
InspectorClientProtocol (and the test fake) so hooks can read them.
- Add PendingClientRequestModal, an App-level modal that surfaces one
queued request at a time (sampling-first) via the existing
SamplingRequestPanel / ElicitationFormPanel / ElicitationUrlPanel. It is
non-dismissable so the blocked call only resolves via an explicit action.
- Wire it in App.tsx: responding/rejecting resolves the client's handler
Promise, which unblocks the originating call and clears the spinner.
Also fold in two issues surfaced while verifying:
- SchemaForm rendered an `array` + `items.enum` (multi-select enum) as a
JSON textarea because only `items.anyOf` had a branch; add a MultiSelect
branch with enumNames label support.
- ToolsScreen's result lives in App and outlived the screen's local
selection (reset on tab-switch unmount), leaving a result with no
selected tool. Clear the result on unmount for a clean slate on return.
Prompts/Resources gate their preview on selection, so they are unaffected.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(elicitation): support explicit decline; honest queue label; review polish
Address @claude review on #1411:
- Add an explicit "Decline" action to ElicitationFormPanel so the spec's
decline (refusal) is distinguishable from cancel (dismissal); the JSDoc
claimed accept/decline/cancel but only accept/cancel were wired. Wire the
modal body to emit { action: "decline" }.
- Replace the misleading "1 of N" queue label (the leading 1 never changed
since the modal always shows the head) with an "N pending" hint, hidden when
nothing else is queued.
- Make the dead useMemo honest: derive the head request inside the memo from
the source arrays so it actually caches (the inline activeElicitation had a
fresh identity every render).
- Document the URL elicitation accept-on-open semantic with a comment pointing
at the follow-up (#1415).
- Add an App-level round-trip test driving pendingSamplesChange end-to-end
(modal opens, respond() fires, empty event closes it).
Follow-ups filed: #1415 (URL two-step completion flow), #1416 (form required-
field submit gate + double-submit guard).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(elicitation): include untouched schema defaults in submitted content
The schema form displays a field's default via resolveValue(), but onChange
only writes a field into `values` once the user edits it. So an elicitation
submitted with default-only fields left untouched dropped them entirely —
v2 sent just the manually-edited fields while v1 sent defaults too (reported
with the everything server: firstLine/integer/number/enum defaults missing).
Add collectSchemaDefaults() to jsonUtils (recurses nested objects, omits
fields with no default) and seed ElicitationFormModalBody's values state with
it via a lazy initializer. The modal body is keyed by request id, so it
re-seeds per request; user edits still override seeded defaults via the
existing onChange merge.
Tests: collectSchemaDefaults unit tests (field types, nested, empty) in
jsonUtils.test; a modal test asserting an untouched-default form still submits
its defaults in content.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(forms): seed schema defaults for tool-call and app-launch forms too
Extend the elicitation defaults fix (collectSchemaDefaults) to the other two
SchemaForm consumers that own form state and submit it: ToolsScreen (tool
execute args) and AppsScreen (app launch args). Both reset formValues to {} on
selection, so default-only fields the user never edited were dropped from the
submitted args — same root cause as the elicitation modal.
Seed formValues from the selected tool/app inputSchema defaults on select.
User edits still override via the existing onFormChange merge.
(InlineElicitationRequest has no consumers wired up, so it's left as-is.)
Tests: ToolsScreen sends a tool's default on Execute without editing;
AppsScreen sends an app's default on Open App without editing.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* feat(elicitation): gate form submit on required fields; guard double-submit (#1416)
Fold the #1416 hardening into this PR:
- Gate the elicitation form's Submit button on required fields. Promote the
hasMissingRequiredFields helper out of AppDetailPanel into jsonUtils (shared)
and use it in ElicitationFormPanel so Submit is disabled until every required
field has a value.
- Guard against double-submit. Add an optional `busy` prop to the sampling,
elicitation-form, and elicitation-url panels that disables their responding
actions. PendingClientRequestModal's bodies use a new ref-guarded
useRespondOnce() hook: the first action dispatches and locks the panel; later
clicks no-op. This stops a fast double-click from calling respond()/reject()
twice (which throws and produced an unhandled rejection). Copy URL stays
enabled — it doesn't resolve the request.
Tests: hasMissingRequiredFields unit tests; ElicitationFormPanel submit-gate
and busy-lock tests; a modal double-click-resolves-once test.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(tools): cap detail/result panels at viewport and scroll internally
The Tools screen's detail and result columns sized to their content and bled
past the bottom of the viewport on long output (e.g. the env dump or a long
elicitation result). Cap each column at the screen's available height and let
its panel scroll internally instead.
- ToolsScreen: drop `align: flex-start` and wrap each column in a stretched
`ContentPane` (Flex column, capped by `mah` = viewport − header − xl*2). The
pane's definite height is what lets the card's inner ScrollArea know how far
to shrink — a bare `mah` on the card does not (the card sizes to content, so
the scroll region renders full-height and overflow:hidden just clips it,
unreachable). Mirrors the proven Prompts/Resources preview panes.
- ToolResultPanel: pinned header + inner ScrollArea (flex 0 1 auto, mih 0).
- ToolDetailPanel: pinned title/annotations header, scrolling body
(description + form + progress), pinned Execute footer.
Audited the other screens: Prompts/Resources already use this pattern,
ServerList and the four list panels (Logging/Network/History/Tasks) already cap
via ScrollArea.Autosize. Only AppsScreen's app-input form had the same gap —
fixed it the same way: AppDetailPanel now scrolls internally and the card uses
variant="preview" so the running app's iframe and a long form both stay within
the viewport.
Verified in-browser against the everything server: the get-env result now
stops at the viewport bottom with margin and scrolls within the card
(clientHeight 502 vs scrollHeight 1931), header pinned.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test(remote): use sync pino destinations in logging tests to fix teardown race
CI flaked with an uncaught `ENOENT: ... /tmp/inspector-log-unknown-level-*/app.log`
that failed an unrelated later test. The remote-logging integration tests create
`pino.destination(logFile)` loggers (async sonic-boom streams) and rmSync the temp
dir in finally/afterEach without closing the stream — a buffered background flush
then fires after the dir is gone and throws an uncaught error, which Vitest counts
as a run failure even though all tests pass.
Make those destinations `sync: true` so the write lands during the request instead
of on a later flush, removing the race. Test-only; unrelated to this PR's feature
work but it was blocking the PR's CI.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cliffhall