feat(web): URL elicitation — explicit completion step + error-path (-32042) handling (#1415) (#1436)
* feat(web): two-step URL elicitation completion (#1415) Replace accept-on-open with an explicit completion step for URL elicitations. Opening the URL now only transitions the panel to its waiting state; the elicitation resolves with `accept` only when the user clicks the revealed "I've completed it" action, or with `cancel`. - ElicitationUrlPanel: add `onComplete`, reveal the completion button and relabel open→"Reopen in Browser" while `isWaiting`. - PendingClientRequestModal: wire local `isWaiting`; open no longer sends a response. Removed the accept-on-open comment that pointed here. - Tests cover open→waiting→complete and open→cancel, and assert opening alone does not resolve the elicitation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat(web): handle URL-elicitation-required (-32042) error path Implements the spec's "URL mode with elicitation required error" flow (2025-11-25). When a tools/call returns a `-32042` UrlElicitationRequired error, the client now surfaces the required URL elicitation(s) and retries the call once completed, instead of showing a bare error. Core (InspectorClient.callTool): - Detect `-32042` (typed UrlElicitationRequiredError or generic McpError) via the new `getUrlElicitationsFromError` helper. - Surface each carried elicitation in order through the existing pending- elicitation queue / modal (reusing the two-step "Open → I've completed it" UI), then re-issue the original call once all are accepted. A decline/cancel aborts with a clear message; a bounded retry count guards a server that keeps returning the error. - `ElicitationCreateMessage.completeIfPending()` lets the optional `notifications/elicitation/complete` auto-advance/auto-accept an open URL elicitation; the completion-notification handler now resolves (was: only removed) the pending entry. - Extracted `attemptToolCall` / `dispatchFailedToolCall` from the old callTool body to support the retry loop without duplicating bookkeeping. Web (App): - A non-spec `-32042` with no elicitations (nothing to open) shows a dedicated yellow toast linking to a new UrlElicitationErrorModal with the raw error body, mirroring the output-schema-validation toast. Tests: helper unit tests, completeIfPending unit tests, callTool error-path retry/cancel/no-list/ordinary-error tests (injected fake client), the new modal (test + stories), and an App toast test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat(web): abort URL-elicitation error path on a repeated URL Guard the -32042 retry loop: if the server's retry error re-requests a URL the user already completed earlier in the same call, completing it again can't make progress, so callTool aborts with a new typed UrlElicitationLoopError instead of re-prompting (which would loop until the retry cap). The web layer detects it and shows a "URL elicitation loop" toast naming the repeated URL rather than a generic failure. Tests: core abort-on-repeat test (URL presented once, two attempts, then loop error) and an App loop-toast test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(web): let Copy-URL reach the URL-elicitation completion step Address review of #1436: the "I've completed it" action was gated behind clicking "Open in Browser" (only that set isWaiting), so a user who used Copy URL to finish the flow externally could only Cancel. Copying the URL now also moves the panel into the waiting state, exposing the completion step. Also trims the now-redundant second sentence of the waiting hint. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(core): address review of error-path URL elicitation Review follow-ups on #1436 (all non-blocking): - Remove the leftover bare block scope in attemptToolCall (extraction artifact); body de-indented one level. - Log a warning when callTool gives up after the URL-elicitation retry cap is hit, so a server that keeps demanding new elicitations is diagnosable rather than looking like an ordinary failure. - Assert the dispatch-once invariant on the loop-abort and cancel-abort paths (exactly one failed toolCallResultChange event). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * style(core): fix attemptToolCall body indentation Run prettier over the extracted attemptToolCall method body, which was left over-indented by 2 spaces after the bare-block removal in 0754b43d. core/ is outside clients/web's format:check scope, so npm run validate did not catch it. Whitespace-only; the pre-existing line 658 wrap (also outside the format scope) is left as-is, out of scope for this PR. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(core): settle pending elicitations on disconnect to avoid callTool hang Address review of #1436: an error-path `awaitUrlElicitation` promise only settled via respond, but `disconnect()` cleared `pendingElicitations` wholesale — so a disconnect mid-elicitation (server crash, manual disconnect, transport close) left `callTool` (and the UI's in-flight toolCallState) hanging forever. - Add `ElicitationCreateMessage.cancel()`: settles a pending elicitation as `{ action: "cancel" }` without calling `onRemove` (the queue is cleared by the caller, so it must not splice mid-iteration). - `disconnect()` now cancels each pending elicitation before clearing the array, and dispatches `pendingElicitationsChange` (it already did so for samples) so the modal closes on a transport-close teardown too. Tests: disconnect-mid-elicitation settles callTool (no hang); cancel() unit tests (resolves-without-remove, no-op once responded). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Cliff Hall
GitHub
parent
49d6be6987
commit
5cabc1ecd7
1 changed files with 1232 additions and 124 deletions
|
|
@ -23,6 +23,10 @@ import type {
|
|||
InspectorClientEventMap,
|
||||
JsonValue,
|
||||
} from "@inspector/core/mcp/index.js";
|
||||
import {
|
||||
getUrlElicitationsFromError,
|
||||
UrlElicitationLoopError,
|
||||
} from "@inspector/core/mcp/urlElicitation.js";
|
||||
import type { TypedEventGeneric } from "@inspector/core/mcp/typedEventTarget.js";
|
||||
import type {
|
||||
InspectorServerSettings,
|
||||
|
|
@ -98,6 +102,7 @@ import {
|
|||
import { ServerSettingsModal } from "./components/groups/ServerSettingsModal/ServerSettingsModal";
|
||||
import { ConnectionInfoModal } from "./components/groups/ConnectionInfoModal/ConnectionInfoModal";
|
||||
import { OutputValidationModal } from "./components/groups/OutputValidationModal/OutputValidationModal";
|
||||
import { UrlElicitationErrorModal } from "./components/groups/UrlElicitationErrorModal/UrlElicitationErrorModal";
|
||||
import type { OAuthDetails } from "./components/groups/ConnectionInfoContent/ConnectionInfoContent";
|
||||
import { ServerRemoveConfirmModal } from "./components/groups/ServerRemoveConfirmModal/ServerRemoveConfirmModal";
|
||||
import {
|
||||
|
|
@ -223,6 +228,46 @@ const OutputValidationToastMessage = ({
|
|||
</Stack>
|
||||
);
|
||||
|
||||
// Body of the non-spec URLElicitationRequired toast: the server returned a
|
||||
// -32042 error with no `elicitations` list, so there's no URL to open. We keep
|
||||
// the toast short and link to a modal with the raw error body.
|
||||
const UrlElicitationErrorToastMessage = ({
|
||||
onViewDetails,
|
||||
}: {
|
||||
onViewDetails: () => void;
|
||||
}) => (
|
||||
<Stack gap={4}>
|
||||
<Text size="sm">
|
||||
The server reported a URLElicitationRequired error but listed no required
|
||||
elicitations, so there's nothing to open.
|
||||
</Text>
|
||||
<Anchor component="button" type="button" size="sm" onClick={onViewDetails}>
|
||||
View error details
|
||||
</Anchor>
|
||||
</Stack>
|
||||
);
|
||||
|
||||
function errorMessage(err: unknown): string {
|
||||
return err instanceof Error ? err.message : String(err);
|
||||
}
|
||||
|
||||
// Pretty-print a thrown error for the URL-elicitation details modal: an McpError
|
||||
// carries a `code`/`data` worth showing alongside the message, so include them
|
||||
// when present; otherwise fall back to the plain message.
|
||||
function formatErrorDetails(err: unknown): string {
|
||||
if (err && typeof err === "object") {
|
||||
const e = err as { code?: unknown; message?: unknown; data?: unknown };
|
||||
if (e.code !== undefined || e.data !== undefined) {
|
||||
return JSON.stringify(
|
||||
{ code: e.code, message: e.message, data: e.data },
|
||||
null,
|
||||
2,
|
||||
);
|
||||
}
|
||||
}
|
||||
return errorMessage(err);
|
||||
}
|
||||
|
||||
// How long a progress toast lingers after its last tick. Each new tick on the
|
||||
// same progress stream resets this window (via `notifications.update`), so a
|
||||
// steady stream keeps one toast alive; the toast clears a few seconds after
|
||||
|
|
@ -339,6 +384,12 @@ function App() {
|
|||
toolName: string;
|
||||
message: string;
|
||||
} | null>(null);
|
||||
// Raw body for the non-spec URLElicitationRequired (-32042, no elicitations)
|
||||
// modal opened from its warning toast.
|
||||
const [urlElicitationErrorDetails, setUrlElicitationErrorDetails] = useState<{
|
||||
toolName: string;
|
||||
details: string;
|
||||
} | null>(null);
|
||||
|
||||
// The active connection target. `null` between sessions; set as soon as
|
||||
// the user toggles a server card on. Drives state-manager lifetime.
|
||||
|
|
@ -1258,9 +1309,50 @@ function App() {
|
|||
error: invocation.error,
|
||||
});
|
||||
} catch (err) {
|
||||
// The server kept asking for a URL the user already completed this call,
|
||||
// so callTool aborted to avoid an endless re-prompt loop. Surface that
|
||||
// explicitly rather than as a generic failure.
|
||||
if (err instanceof UrlElicitationLoopError) {
|
||||
setToolCallState({ status: "error", error: err.message });
|
||||
notifications.show({
|
||||
autoClose: false,
|
||||
title: "URL elicitation loop",
|
||||
color: "yellow",
|
||||
message: (
|
||||
<Text size="sm">
|
||||
The server requested the same URL again after you completed it (
|
||||
{err.url}), so the call was cancelled to avoid an endless loop.
|
||||
</Text>
|
||||
),
|
||||
});
|
||||
return;
|
||||
}
|
||||
// A URLElicitationRequired (-32042) error that reaches here carried no
|
||||
// elicitations (a non-spec response — the with-list case is handled and
|
||||
// retried inside callTool). There's no URL to open, so surface a short
|
||||
// toast that links to the raw error rather than a bare error panel.
|
||||
const urlElicitations = getUrlElicitationsFromError(err);
|
||||
if (urlElicitations !== null && urlElicitations.length === 0) {
|
||||
const details = {
|
||||
toolName: name,
|
||||
details: formatErrorDetails(err),
|
||||
};
|
||||
setToolCallState({ status: "error", error: errorMessage(err) });
|
||||
notifications.show({
|
||||
autoClose: false,
|
||||
title: "URL elicitation required",
|
||||
color: "yellow",
|
||||
message: (
|
||||
<UrlElicitationErrorToastMessage
|
||||
onViewDetails={() => setUrlElicitationErrorDetails(details)}
|
||||
/>
|
||||
),
|
||||
});
|
||||
return;
|
||||
}
|
||||
setToolCallState({
|
||||
status: "error",
|
||||
error: err instanceof Error ? err.message : String(err),
|
||||
error: errorMessage(err),
|
||||
});
|
||||
}
|
||||
},
|
||||
|
|
@ -1953,6 +2045,12 @@ function App() {
|
|||
message={outputValidationDetails?.message}
|
||||
onClose={() => setOutputValidationDetails(null)}
|
||||
/>
|
||||
<UrlElicitationErrorModal
|
||||
opened={urlElicitationErrorDetails !== null}
|
||||
toolName={urlElicitationErrorDetails?.toolName}
|
||||
details={urlElicitationErrorDetails?.details}
|
||||
onClose={() => setUrlElicitationErrorDetails(null)}
|
||||
/>
|
||||
<PendingClientRequestModal
|
||||
request={pendingRequestContent}
|
||||
serverName={activeServer?.name ?? "this server"}
|
||||
|
|
|
|||
Loading…
Reference in a new issue