Solid useChat drops earlier turns after a reactive request option changes
Los mantenedores suelen responder en 1 día
@AlemTuzlak ya está trabajando en esto.
Desde el 28/9/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
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, pnpm11.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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 3.1k
- Forks
- 340
- Merge medio
- 2 d 10 h
- PR fusionados (30 d)
- 175
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de TanStack/ai
-
update elevenlabsPosiblemente ocupada @tombeckenham la tomó hoy. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
onAfterToolCall failure records a second, contradictory result for a successful server toolPosiblemente ocupada @AlemTuzlak la tomó hace 1 día. Abiertohas-pr waiting-on: maintainer
TanStack/ai#1558 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
SSE and NDJSON response streams drain unread sources without backpressurePosiblemente ocupada @tombeckenham la tomó hace 1 día. Abiertohas-pr waiting-on: maintainer
TanStack/ai#1556 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Tool calls from one model step run one at a time, but the docs say they run in parallelPosiblemente ocupada @tombeckenham la tomó hace 1 día. Abiertowaiting-on: maintainer
TanStack/ai#1547 · 1 reacción · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
OpenRouter adapters: optional tool fields cannot be omitted (Chat Completions) or fail validation (Responses)Posiblemente ocupada @tombeckenham la tomó hace 1 día. Abiertohas-pr waiting-on: maintainer
TanStack/ai#1542 · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de TanStack/ai
Issues similares
-
priority: P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
prime-radiant-inc/evener#3291 ·
Los mantenedores suelen responder en 1 día
-
accessibility bug revealjs
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
quarto-dev/quarto-cli#14961 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
supabase/agent-skills#614 ·
-
Content
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
RunestoneInteractive/rs#1559 · 1 comentario ·
Los mantenedores suelen responder en 2 días