Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Solid useChat drops earlier turns after a reactive request option changes

Abierto
#1,552 0 comentarios 0 reacciones 1 asignado Ver en GitHub

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

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.
Lenguaje dominante
TypeScript
Estrellas
3.1k
Forks
340
Merge medio
2 d 10 h
PR fusionados (30 d)
175

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de TanStack/ai

Todos los issues de TanStack/ai

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.