refactor: remove dead WebSocket history handlers#16207
Conversation
Remove handleHistoryRequest, handleConversationSearch, handleMessageContentRequest, and lightModeSurfaceData — these WebSocket handlers are no longer called anywhere. The macOS app uses HTTP endpoints that call the shared business logic (performConversationSearch, getMessageContent) directly. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…e types Remove getMessagesPaginated (only caller was the deleted handleHistoryRequest) along with its PaginatedMessagesResult interface and now-unused drizzle-orm imports (asc, lt, or) and crud imports (parseMessage, MessageRow). Remove HistoryRequest, ConversationSearchRequest, and MessageContentRequest interfaces from sessions.ts — these were parameter types for the removed WebSocket handlers and are not referenced by any dispatcher or other code. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@codex review |
There was a problem hiding this comment.
🚩 HistoryResponse and related server types retained despite handler removal
The PR removes the HistoryRequest client message type and the handleHistoryRequest handler, but retains HistoryResponse, HistoryResponseToolCall, and HistoryResponseSurface in assistant/src/daemon/message-types/sessions.ts:248-314. These are still included in _SessionsServerMessages at line 412. This is presumably correct if the HTTP route layer still constructs and sends HistoryResponse messages, but it's worth confirming these response types are actually still used somewhere (likely in the HTTP history endpoint). If they're also dead, they should be removed per the AGENTS.md dead code removal rule.
(Refers to lines 248-314)
Was this helpful? React with 👍 or 👎 to provide feedback.
| | ConversationSearchRequest | ||
| | MessageContentRequest | ||
| | ReorderThreadsRequest; | ||
|
|
There was a problem hiding this comment.
🚩 ConversationSearchResponse retained in server messages union without corresponding client request type
The ConversationSearchRequest client type was removed from _SessionsClientMessages, but ConversationSearchResponse (sessions.ts:145-149) is still in _SessionsServerMessages at line 422. This is expected if the HTTP route (GET /v1/conversations/search in session-query-routes.ts) returns search results through the HTTP response body rather than through the WebSocket message union. However, having ConversationSearchResponse in the WebSocket server message union with no corresponding WebSocket client request type is asymmetric. It's not a bug if the type is used elsewhere (e.g., for type reuse in HTTP responses), but worth noting.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Codex Review: Didn't find any major issues. 🚀 ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
1 participant
Summary
assistant/src/daemon/handlers/session-history.ts:handleHistoryRequest,handleConversationSearch,handleMessageContentRequest, andlightModeSurfaceDataTest plan
npx tsc --noEmit)performConversationSearch,getMessageContent,ConversationSearchParams,MessageContentResult) is preserved and still exported🤖 Generated with Claude Code