Using JSON.parse(JSON.stringify(context)) for deep cloning is a common pattern, but it can have a performance impact, especially in high-frequency hooks like onTokenLiteral. This method is relatively slow for large objects and has limitations (e.g., it drops undefined values and converts Date objects to strings). Since this pattern is repeated for all broadcastStreamEvent calls in this file, consider creating a more performant deep-clone utility or using a lightweight library like rfdc if you notice any UI lag during message streaming. This would also improve maintainability by centralizing the cloning logic.

This logic to extract the discord metadata from the context is duplicated here and in the onChatTurnComplete hook below (lines 164-171). To improve maintainability and reduce redundancy, consider extracting this into a small helper function.

For example, you could define a helper function like this within the store:

function getDiscordMetadataFromContext(context: ChatStreamEventContext): any | undefined {
  const inputContent = Array.isArray(context.input.content)
    ? context.input.content.map(c => c.type === 'text' ? c.text : '').join('')
    : context.input.content;

  if (typeof inputContent === 'string' && inputContent.includes('(From Discord user')) {
    return Object.values(context.contexts).flat().find(c => c.metadata?.discord)?.metadata?.discord;
  }
  return undefined;
}

Then you can simply call this function in both places.

/gemini review

Having getDiscord...(...) implementation here and handles specifically for Discord is not extendable for future integrations, what approach would you suggest to have both Discord context builder and other source/module integrated in? Perhaps, can we ask the input:text to build essential messages / context for consumer side from the module that initially emits? What is the best option here?

You raise a very good point regarding the extendability of the getDiscordContextFrom helper. Relying on a string pattern in the message content ((From Discord user) and a hardcoded metadata key (discord) makes the solution less flexible for integrating other platforms like Telegram or Slack in the future.

Your suggestion to have the input:text event build and carry essential context from the module that initially emits it is indeed the best approach for a more generic and maintainable solution. The current implementation already does this by including the discord object in the input:text event data, which is then ingested into a ContextMessage with source: 'discord' and metadata: { discord: { ... } }.

To make the context extraction more generic and leverage this existing structure, we can modify the helper function to primarily use the source property of the ContextMessage objects within the ChatStreamEventContext. This separates the identification of the message's origin from the specific content of the message itself, allowing the (From Discord user X) marker to serve its intended purpose for the LLM, as mentioned in the PR description.

Here's a more generic helper function that you could use:

function getPlatformSpecificMetadata(context: ChatStreamEventContext, platformName: string): any | undefined {
  // Find a ContextMessage that explicitly states its source as the given platform
  const platformContextMessage = Object.values(context.contexts).flat().find(c => c.source === platformName);
  // Return the metadata associated with that platform, assuming it's structured as { platformName: { ... } }
  return platformContextMessage?.metadata?.[platformName];
}

Then, in onAssistantMessage and onChatTurnComplete, you would use it like this:

const discord = getPlatformSpecificMetadata(context, 'discord');
if (discord) {
  serverChannelStore.send({
    type: 'output:gen-ai:chat:message',
    data: {
      message,
      discord,
      // ... other data
    },
  });
}

This approach is more extendable because:

• Source Identification: It relies on the source field of the ContextMessage, which is a programmatic identifier for the platform, rather than a string pattern in the message content.
• Generic Metadata Retrieval: It retrieves platform-specific metadata based on a consistent key (platformName) within the ContextMessage.metadata object.
• Clearer Intent: The (From Discord user X) marker in the message content can then be understood purely as an instruction for the LLM, without being part of the routing logic within the context-bridge.

Using as any bypasses TypeScript's type safety. It would be more robust to define a specific type for the data payload of the output:gen-ai:chat:message event and use that for casting. This improves code clarity and prevents potential runtime errors if the data structure changes.

For example, you could define a type like this (preferably in a shared location):

interface ChatMessageOutput {
  message: { content: string };
  discord?: { channelId: string };
}

Casting the event data to any bypasses TypeScript's type safety. A better approach is to construct a fully typed event object before sending it. This ensures the payload matches the expected type for an input:text event and makes the code more robust.

Additionally, the nickname field is redundant because displayName already provides the server-specific nickname if one is set. The receiving end in context-bridge.ts only uses displayName.

You can define a type for the data payload and create a typed object, which resolves both issues.

Example type definition:

interface TextInputData {
  text: string;
  discord: {
    channelId: string;
    guildId: string | null;
    guildMember: {
      id: string;
      displayName: string;
    };
  };
}

        const data = {
          text: content,
          discord: {
            channelId: message.channelId,
            guildId: message.guildId,
            guildMember: {
              id: message.author.id,
              displayName: message.member?.displayName ?? message.author.username,
            },
          },
        };

        this.airiClient.send({
          type: 'input:text',
          data,
        })

I am so sorry that the server-shared/channel-server's type is not finalized and still experimenting. Is context:update ok for consuming the input:text event from Discord? Should we do spark:notify instead?

Nice work here. This reminds me that having a context formatter is essential to all integrations.

Oh I see, so here use as context:update is fine since you use chatStore.send(...) for reacting to stage.

Yes exactly, I used input:text to trigger a direct chat interaction which feels more natural for a direct reply pattern.

Can we not to use any here?

Absolutely. I'll refactor this to use a property check instead of any to ensure the channel is sendable while keeping it type-safe.