feat(web): History — Pin & Replay, plus two history-status fixes (#1438)

[cliffhall]

History-screen work. Three related changes on one branch.

1. Pin & Replay (#1438)

Both HistoryEntry actions were rendered but wired to todoNoop in App.

• Pin — App owns a session-scoped Set<string> of pinned entry ids, toggled by onTogglePinHistory and passed down as pinnedHistoryIds. HistoryListPanel already sorts pinned entries to the top. The set resets with the rest of the per-screen state on disconnect / server-switch.
• Replay — onReplayHistory re-issues the entry's original request by method: tools/call → callTool, prompts/get → getPrompt, resources/read → readResource. The call flows through InspectorClient → tracked transport → message log, so the fresh request+response surface as a new History entry (history-local) without touching the Tools/Prompts/Resources panels. An unsupported method or a removed tool surfaces a toast.

2. Notifications no longer stuck "Pending" (#1439)

extractStatus derived the badge purely from whether a response was attached, so a fire-and-forget notification (no id, no response) — and any unmatched standalone response — showed Pending forever. The pending→OK/Error lifecycle only applies to direction === "request" entries; non-request entries now render no request-style badge (the method badge already labels them).

3. Server→client requests resolve in history (#1440)

MessageTrackingTransport.send only tracked outgoing requests, so the client's response to a server→client request (roots/list, sampling, elicitation) was never recorded — the request sat Pending with no response body. send is now symmetric with onmessage: it tracks outgoing responses (by id + result/error) too, so the response folds into its request entry and resolves to OK/Error. (Verified the integration "no orphan responses" assertion still holds.)

Testing

• npm run validate — 2070 unit/integration tests pass; per-file coverage gate green.
• npm run test:storybook — 333 pass.

Closes #1438, closes #1439, closes #1440.

🤖 Generated with Claude Code

4. Direction badge on History & Network (#1437)

A shared dual-state badge at each entry's top-left shows travel direction: client → server (green, inspector-originated) / client ← server (violet, server-originated). History derives it from a new MessageEntry.origin field set at tracking time (MessageTrackingTransport tags outgoing send as client, incoming onmessage as server). Network fetches are always inspector-originated, so the badge there is constant (outgoing) — the light "tap" noted in the issue.

Closes #1437.

[cliffhall]

@claude review

[claude]

Claude finished @cliffhall's task in 2m 17s —— View job

---

Code Review — PR #1441 (History: Pin & Replay + status fixes)

I reviewed the full diff against origin/v2/main. Overall this is clean, well-factored, and well-tested — single source of truth for replayable methods, a shared MessageDirectionBadge/ExpandToggle/PinToggle extracted from the duplicated subtle-buttons, and the core transport fix is symmetric and correct. Below are findings, none blocking.

✅ What's solid

• messageTrackingTransport.send (History: server→client requests (roots/list, sampling, elicitation) stuck Pending with no response body #1440) — the new outgoing-response branch correctly uses message.id !== null && message.id !== undefined rather than a falsy check, so a JSON-RPC id of 0 is still tracked. The classification (result/error → response, else method → request) mirrors onmessage exactly, and the new test file covers request/response/error/notification cases plus base-transport forwarding.
• extractStatus → "none" (History: server notifications show a permanent PENDING status badge #1439) — gating the pending→OK/Error lifecycle on direction === "request" is the right fix; notifications and unmatched standalone responses no longer render a permanent "Pending". The method badge already labels them.
• REPLAYABLE_HISTORY_METHODS single source of truth — HistoryEntry (button visibility) and App.replayHistoryRequest (dispatch gate) both read it, so they can't drift. Nice.
• clearMessages predicate semantics — verified against messageLogState.ts:130 (predicate = remove). onClearHistorySection passes has(id) for pinned / !has(id) for history, which is correct, and the pinned set is reset when the pinned section is cleared.
• EMPTY_HISTORY_UI was updated with visibleDirections: { client: true, server: true } and is reset on disconnect — no stale-state leak.

🔸 Observations / minor

1. Outgoing client notifications remain untracked — the one residual asymmetry. send only tracks messages with an id, so the client's own notifications (notifications/initialized, notifications/progress, notifications/roots/list_changed) never reach history, while incoming server notifications are tracked via onmessage. Your test documents this as intentional, but it slightly undercuts the "send is now symmetric with onmessage" framing in the PR body. Worth confirming this is deliberate — if outgoing notifications should appear in History, send needs an else if ("method" in message) → trackNotification(…, "client") branch.

2. Per-section Clear/Export ignore the active direction & search filters. onClearHistorySection/onExportHistorySection operate on the full unfiltered log by pin membership. So clearing the "pinned" section while a direction filter hides some pinned entries still removes all pinned entries — including the ones not currently visible. Defensible ("clear the section = clear the section"), but it can surprise a user who's filtered the view. Consider either respecting the visible set or leaving as-is intentionally.

3. PR description vs. code: incoming badge color. Section 4 of the description says incoming is yellow; the code uses violet (and MessageDirectionBadge's comment explains why not yellow — green+yellow reads as ok/caution status, not direction). Code is internally consistent (HistoryControls also uses violet); just the prose is stale.

4. replayHistoryRequest default: branch is dead code. It's gated by isReplayableHistoryMethod and the switch enumerates every member of the set, so default is unreachable. Harmless defensive belt-and-suspenders, but you could drop it (or keep for safety — your call).

5. Replaying a tools/call re-runs side effects with no confirmation. Inherent to the feature and fine, but a destructive tool will execute again silently on Replay. Not a change request — just flagging the behavior is by design.

Nits

• MessageDirectionBadge color names (green/violet) and HistoryControls' Text c={color} use Mantine palette names — consistent with the AGENTS.md token rules (named colors, no hex). 👍
• New element components aren't enumerated in any README, and the READMEs don't list individual elements, so no doc update is owed.

No correctness blockers found. Items 1 and 2 are the only ones I'd ask you to consciously confirm-or-tweak before merge.

[cliffhall]

Thanks for the thorough review! Addressed in 96471f8d.

1. Outgoing client notifications untracked — fixed. Good call; I made send truly symmetric with onmessage. It now also tracks the client's own notifications (initialized, progress, roots/list_changed) as origin client via the else if ("method" in message) branch, so they surface in History (showing client → server) just like incoming server notifications. Updated the transport test (the old "does not track an outgoing notification" case now asserts it is tracked as a client notification). Integration suite still green.

2. Per-section Clear/Export ignore active filters — intentional, left as-is. They operate on the full section by pin membership, matching the existing panel-level Clear/Export (which also ignore the search/method/direction filters). Keeping all three consistent felt less surprising than having section actions respect filters while the panel ones don't — "clear the section = clear the section." Happy to revisit if we later make the panel-level ones filter-aware too.

3. PR description (yellow vs violet) — fixed. Updated section 4 of the description to say violet; the code/comment were already correct.

4. replayHistoryRequest default branch — keeping it. It's unreachable at runtime (gated by isReplayableHistoryMethod + the switch enumerates every set member), but TS can't prove the gate guarantees membership, so without default the function fails "not all code paths return." So it stays as the required return — belt-and-suspenders that also satisfies the compiler.

5. Replay re-runs side effects — by design, acknowledged. Replaying a tools/call re-executes it (including destructive tools) with no confirmation, same as invoking it from the Tools screen. Noting it's intentional; a confirm-on-destructive affordance would be a separate enhancement.

Nits — agreed, no changes owed.

Re-validated: npm run validate (2094) + npm run test:storybook (339) green.

@claude review

[claude]

Claude finished @cliffhall's task in 1m 0s —— View job

---

Follow-up review — 96471f8d (outgoing client notifications)

• Review outgoing client notification tracking change
• Confirm transport send/onmessage symmetry
• Check test coverage for new branch
• Post review

Thanks for the thorough write-up — I re-read the diff against origin/v2/main and the follow-up commit. All five items are handled correctly; nothing left to change.

✅ Item 1 — outgoing client notifications (the one substantive change)

MessageTrackingTransport.send is now genuinely symmetric with onmessage:

if ("id" in message && message.id !== null && message.id !== undefined) {
  if ("result" in message || "error" in message) trackResponse(…, "client");
  else if ("method" in message)                  trackRequest(…, "client");
} else if ("method" in message) {
  trackNotification(message as JSONRPCNotification, "client");   // ← new
}

This now mirrors the onmessage branch structure exactly (messageTrackingTransport.ts:56-70 vs :115-136), the only difference being the "client" vs "server" origin tag — which is precisely the intended asymmetry. I traced it through the rest of the pipeline and it holds end-to-end:

• No permanent "Pending". A client notification lands as direction: "notification", and extractStatus returns "none" for anything that isn't a request (HistoryEntry.tsx:83) — so no request-style badge. ✔
• Correct direction badge. origin: "client" → MessageDirectionBadge direction="outgoing" → green client → server (HistoryEntry.tsx:127-129). ✔
• Respects the direction filter. matchesFilters keys visibility off entry.origin (HistoryListPanel.tsx:156), so the new client notifications honor the client/server toggle. ✔
• Test updated, not just flipped. The old "does not track" case is now a positive assertion that trackNotification is called with (notification, "client") while trackRequest/trackResponse are not — a precise replacement, not a loosened one (messageTrackingTransport.test.ts:66-79). ✔

One thing worth a passing note (no action needed): send will now also track notifications/initialized and any notifications/cancelled the client emits, not just the three you listed — which is the correct, fully-symmetric behavior, just slightly broader than the commit message's examples imply.

✅ Items 2–5

• 2 (per-section Clear/Export ignore filters) — agreed, consistency with the panel-level actions is the right call. "Clear the section = clear the section" is defensible and now matches the existing behavior rather than diverging from it.
• 3 (yellow→violet prose) — description updated; code/comment were already correct.
• 4 (default: branch) — correct, it's the required return that satisfies TS's "not all code paths return," not redundant defensiveness. Keep it.
• 5 (replay side effects) — by design, acknowledged; confirm-on-destructive is a fair follow-up.

Verdict

No correctness issues. The transport fix is the load-bearing change and it's clean, symmetric, and covered. 👍 LGTM.
• feat/history-pin-replay-1438

[cliffhall]

Thanks — appreciate the careful re-trace. Confirming your passing note: yes, send now tracks all client-originated notifications (initialized, cancelled, progress, roots/list_changed, …), not just the three I listed — that's the intended fully-symmetric behavior; the commit examples were just illustrative.

No further changes. Ready to merge whenever. 🙏