Repository navigation
Calls that return the server's answer (GRYT-2005, 1/2) - #18
Merged
Merged
Conversation
history, thread, search, startThread and diagnostics each emit and wait for the matching reply, with a 10 second timeout. send resolves with the posted message by matching its nonce, and can reply or post into a thread. members and channels keep the last lists the server sent. fetch is left as it was. It never had a chat:history listener, so it has never answered anything; history is the working version. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
grytchat
marked this pull request as ready for review
November 3, 2026 10:39
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First layer of the Gryt MCP stack (GRYT-2005). The second layer, #19, adds the
gryt-mcpcommand on top of these calls.Before this, a bot could send and listen, but it couldn't ask for something and get the answer back.
fetchemittedchat:fetchand said the answer comes on themessageevent, but nothing listens forchat:history, so it never answered.New calls, each emitting and then waiting for the matching reply, with a 10 second timeout:
history(conversationId, { limit, before }): a page of a channel, plus the threads on itthread(conversationId, threadId, …): a thread's root and repliessearch({ query, conversationId, senderServerUserId, before, after })startThread(conversationId, rootMessageId, title?)diagnostics(): needsview_diagnostics, from server#358sendnow resolves with the message it posted, matched by nonce, and takesreplyToandthreadId.bot.membersandbot.channelskeep the last lists the server sent, andMessagecarriesthreadId.Look at
request()inclient.ts. An error event rejects whatever is waiting on it, because the server doesn't say which call achat:erroranswers. Two calls at once on the same bot can steal each other's refusal. The MCP makes one call at a time.sendused to return as soon as it emitted. It now waits for the echo, so a bot that awaitedsendin a loop is slower by one round trip per message.fetchas it was, since removing it would break the public API.Tested with
yarn test, and end to end against a local server from the server branch: every call, through the MCP in #19.🤖 Generated with Claude Code