Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Solid useChat drops earlier turns after a reactive request option changes

Open
  • Is something wrong?
#1,552 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@AlemTuzlak is already working on this.

Since Sep 28, 2026.

Assessment

This issue has not been assessed yet.

Description

has-pr waiting-on: maintainer

TanStack AI version

@tanstack/[email protected] and @tanstack/[email protected], reproduced on TanStack/ai main at 62bec34bb.

Framework/Library version

SolidJS 1.9.10.

Describe the bug and the steps to reproduce it

useChat starts a new ChatClient when a reactive body getter changes, even when the caller has not changed the conversation's threadId. The next send uses the new client's empty transcript. A two-turn conversation then reaches the connection adapter as two separate one-turn requests.

The cause is in packages/ai-solid/src/use-chat.ts. On main, the client is constructed inside createMemo (around line 105). That memo reads options.body while building the ChatClient (around line 140). Solid tracks the signal read by the getter. Updating that signal reruns the memo and constructs a new client. The [clientId] passed as the second argument to createMemo (line 219) is its initial value, not a dependency array. It does not restrict reruns to clientId changes. The effect below the memo then updates options on the newly constructed client; it cannot restore the old transcript.

The following minimal Vitest case uses the repository's existing fake connection adapter. Save it as packages/ai-solid/tests/repro-reactive-body.test.ts on clean main:

import { renderHook } from '@solidjs/testing-library'
import { createSignal } from 'solid-js'
import { expect, it } from 'vitest'
import { useChat } from '../src/use-chat'
import { createMockConnectionAdapter, createTextChunks } from './test-utils'

it('keeps the first turn after a reactive body change', async () => {
  const requests: Array<{ users: number; provider: unknown }> = []
  const connection = createMockConnectionAdapter({
    chunks: createTextChunks('Response'),
    onConnect(messages, data) {
      requests.push({
        users: messages.filter((message) => message.role === 'user').length,
        provider: data?.['provider'],
      })
    },
  })
  const { result } = renderHook(() => {
    const [provider, setProvider] = createSignal('openai')
    const chat = useChat({
      connection,
      get body() { return { provider: provider() } },
    })
    return { chat, setProvider }
  })

  await result.chat.sendMessage('First')
  result.setProvider('anthropic')
  await result.chat.sendMessage('Second')

  expect(requests).toEqual([
    { users: 1, provider: 'openai' },
    { users: 2, provider: 'anthropic' },
  ])
})

Run pnpm --dir packages/ai-solid exec vitest run tests/repro-reactive-body.test.ts. The same case was run in detached checkouts of clean main and the fix branch:

main 62bec34bb: 1 failed
AssertionError: expected [ 1, 1 ] to deeply equal [ 1, 2 ]

fix 589539c82: 1 passed
requests: [{ users: 1, provider: 'openai' },
           { users: 2, provider: 'anthropic' }]

The maintained regression is in the proposed branch. It uses this same public hook and fake adapter. The browser E2E case checks the same two-send path.

Expected behavior

Changing request metadata such as body or forwardedProps should change the next request without changing the ChatClient that owns the transcript. A new threadId should select a new conversation and release the old connection. The current Solid API guide calls threadId the chat's identity, and ChatClient.updateOptions already supports changing wire-payload options without replacing the client.

Impact and scope

This is observable without a provider key: the second call to the connection adapter contains one user message rather than two. A provider therefore lacks the first user turn and its reply when generating the second response. The affected path is Solid useChat with a reactive option getter; this report does not concern per-call sendMessage body forwarding. PR #1227 addressed that separate path, and PR #1232 changes client snapshots rather than the Solid memo.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

Runnable repository test on the proposed branch. The complete main-branch reproduction is inline above and needs no external service.

Screenshots or Videos (Optional)

Not applicable; the request history is asserted directly.

Do you intend to try to help solve this bug with your own PR?

Yes, I am also opening a PR that solves the problem alongside this issue.

Terms & Code of Conduct

  • I agree to follow this project's Code of Conduct.
  • I understand that a bug without a reliable reproduction can be closed.

Environment

  • Node.js 24.11.1, pnpm 11.19.0, Windows 11.
  • The reproduction uses Solid's test harness and a local connection adapter; no provider, browser service, or API key is required.
Dominant language
TypeScript
Stars
3.1k
Forks
340
Avg merge
2d 10h
Merged PRs (30d)
175

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TanStack/ai

All issues in TanStack/ai

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.