messages parameter to fetchServerSentEvents function

[tornado-softwares]

Hi,

I added a messages parameter to the fetchServerSentEvents connection adapter.

You might ask why. It's simple: Transtack AI provides all the tools to create an AI chat, for example, but we still manage our backend as we see fit in a scenario where my chats and messages are saved in a database that I can quickly access.
I don't need the frontend to send me ALL the messages again. The culprit is the React useChat hook from @tanstack/ai-react, and it doesn't directly allow sending only new messages to the backend when sendMessage() function is called.
So I figured the simplest way to implement this would be with a few lines in the connection adapter. I can therefore create something that solves my problem and looks like this:

 const chat = useChat({
    // [ ... ]
    connection: fetchServerSentEvents('/api/chat', async (messages) => {
      return {
        body: {
          // Send last message only :-)
          messages: [messages[messages.length - 1]]
        }
      }
    }),
    // [ ... ]
  })

This pull request doesn't introduce any breaking changes. And I think it could be relevant for certain use cases like mine.

But maybe I'm missing something ? Is there a cleaner, more appropriate way to do this without adding this hacky parameter ? Perhaps by using @tanstack/ai-client ? Anyway, that's how I solved my problem. I'd really like to know if anyone else has had the same question as me and if there's another way to do it.

Thanks.

Summary by CodeRabbit

• New Features
  • Connection options for server-sent events can now be dynamically configured as a function that receives the messages being sent, enabling message-aware connection setup.

[coderabbitai]

📝 Walkthrough

Walkthrough

The fetchServerSentEvents function's options parameter is updated to support a function that receives the messages argument. This allows callers to dynamically determine connection options based on the messages being sent.

Changes

Options Function Resolution Update

Layer / File(s)	Summary
Function Signature & Implementation packages/typescript/ai-client/src/connection-adapters.ts	fetchServerSentEvents now accepts options as a function that takes messages as a parameter. The resolver logic changes from typeof options === 'function' ? await options() : options to typeof options === 'function' ? await options(messages) : options, enabling message-aware connection option resolution.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

A tiny rabbit squeaked with cheer,
"The options function's vision's clear!
With messages now in its grasp,
Connection choices break their clasp!" 🐰
Flexibility hops forth today,
The code dances in a wiser way!" 🌟

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The PR description is comprehensive and includes motivation, use case explanation, and code examples, but does not follow the required template structure with 🎯 Changes, ✅ Checklist, and 🚀 Release Impact sections.	Restructure the description to follow the required template format, ensuring the Checklist items are marked and Release Impact section specifies whether a changeset was generated.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: adding a messages parameter to the fetchServerSentEvents function, which aligns with the code changes and PR objectives.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

packages/typescript/ai-client/src/connection-adapters.ts (2)

264-275: ⚡ Quick win

No test asserts that messages is actually forwarded to the options callback.

The existing test suite (Context snippet 1) covers the zero-arg form but never verifies that the messages array is passed correctly to the new signature. A targeted test — asserting the callback receives the expected messages — would guard against regressions (e.g., a future refactor accidentally reverting to options()).

🧪 Suggested test

it('should pass messages to dynamic options function', async () => {
  fetchMock.mockResolvedValue(mockResponse as any)

  const receivedMessages: Array<any> = []
  const adapter = fetchServerSentEvents('/api/chat', (messages) => {
    receivedMessages.push(...messages)
    return { headers: { 'X-Custom': 'dynamic' } }
  })

  const inputMessages = [{ role: 'user', content: 'Hello' }]
  for await (const _ of adapter.connect(inputMessages as any)) {
    // Consume
  }

  expect(receivedMessages).toEqual(inputMessages)
})

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/typescript/ai-client/src/connection-adapters.ts` around lines 264 -
275, Add a unit test that verifies fetchServerSentEvents forwards the messages
array to a dynamic options callback: create a test that calls
fetchServerSentEvents('/api/chat', (messages) => { record messages; return
options }) then invoke the adapter.connect generator with a known inputMessages
array and iterate it to completion, finally asserting the recorded messages
equal inputMessages; target the fetchServerSentEvents function and its returned
connect generator to ensure the callback receives the messages argument.

---

368-379: ⚡ Quick win

fetchHttpStream has the same pattern but wasn't updated — API inconsistency.

fetchHttpStream is structurally identical to fetchServerSentEvents and the messages-aware options callback is equally useful there (same PR motivation applies). Leaving it at () => FetchConnectionOptions creates a confusing asymmetry where the same pattern works differently across the two adapters.

♻️ Proposed parity fix for `fetchHttpStream`

 export function fetchHttpStream(
   url: string | (() => string),
   options:
     | FetchConnectionOptions
-    | (() => FetchConnectionOptions | Promise<FetchConnectionOptions>) = {},
+    | ((messages: Array<UIMessage> | Array<ModelMessage>) => FetchConnectionOptions | Promise<FetchConnectionOptions>) = {},
 ): ConnectConnectionAdapter {
   return {
     async *connect(messages, data, abortSignal) {
       const resolvedUrl = typeof url === 'function' ? url() : url
       const resolvedOptions =
-        typeof options === 'function' ? await options() : options
+        typeof options === 'function' ? await options(messages) : options

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/typescript/ai-client/src/connection-adapters.ts` around lines 368 -
379, The fetchHttpStream adapter currently resolves options with a parameterless
callback, causing API inconsistency with fetchServerSentEvents; change the
options callback signature so FetchConnectionOptions can be returned from a
function that receives the messages iterator (i.e., from () =>
FetchConnectionOptions to (messages) => FetchConnectionOptions |
Promise<FetchConnectionOptions>), and when resolving options inside
fetchHttpStream (function fetchHttpStream / method connect) call await
options(messages) instead of await options(); update any related types/overloads
for FetchConnectionOptions to accept the messages parameter so the adapter
matches the other messages-aware connection adapters.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@packages/typescript/ai-client/src/connection-adapters.ts`:
- Around line 264-275: Add a unit test that verifies fetchServerSentEvents
forwards the messages array to a dynamic options callback: create a test that
calls fetchServerSentEvents('/api/chat', (messages) => { record messages; return
options }) then invoke the adapter.connect generator with a known inputMessages
array and iterate it to completion, finally asserting the recorded messages
equal inputMessages; target the fetchServerSentEvents function and its returned
connect generator to ensure the callback receives the messages argument.
- Around line 368-379: The fetchHttpStream adapter currently resolves options
with a parameterless callback, causing API inconsistency with
fetchServerSentEvents; change the options callback signature so
FetchConnectionOptions can be returned from a function that receives the
messages iterator (i.e., from () => FetchConnectionOptions to (messages) =>
FetchConnectionOptions | Promise<FetchConnectionOptions>), and when resolving
options inside fetchHttpStream (function fetchHttpStream / method connect) call
await options(messages) instead of await options(); update any related
types/overloads for FetchConnectionOptions to accept the messages parameter so
the adapter matches the other messages-aware connection adapters.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: af930c5a-6652-4a9f-9892-238282243658

📥 Commits

Reviewing files that changed from the base of the PR and between ff33855 and 1a05ff0.

📒 Files selected for processing (1)

• packages/typescript/ai-client/src/connection-adapters.ts