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

Responses Streaming SSE Keepalive

Abierto
  • ¿Algo no está bien?
#11,076 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go
Área
api, backend

Línea de trabajo

Comienza localizando el handler de POST /v1/responses para el streaming en primer plano y su escritor SSE existente. Sigue la validación de la request, la espera antes del primer evento, la cancelación de la request y las escrituras normales del stream; se considera terminado cuando un intervalo sse_keepalive opcional envía comentarios serializados hasta el primer evento, la cancelación o un fallo de escritura, con tests que cubran esos casos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Is your feature request related to a problem? Please describe.

With POST /v1/responses using foreground streaming, queueing and prompt prefill can take a very long time before LocalAI sends response headers or SSE data. Reverse proxies may time out during this silent period.

Foreground streaming is otherwise desirable because disconnecting the client cancels the LocalAI request. Using background: true avoids the timeout, but can leave stale jobs running when a client disconnects or restarts.

Describe the solution you'd like

Add optional SSE keepalive comments for foreground streaming Responses requests, for example:

POST /v1/responses?sse_keepalive=15s

LocalAI would flush an initial SSE comment after synchronous request validation, then periodically send comments while waiting for the first real event:

: keepalive

These should probably remain transport-level comments, not synthetic Responses events. The inference request should remain attached to the HTTP request context so disconnects continue to cancel it.

Describe alternatives you've considered

  • Increasing reverse-proxy timeouts to an hour or more, but this can get ridiculous, complicate reverse proxy config, and won't necessarily work across all network scenarios.
  • Using background Responses and explicitly canceling them, but this can leave a mess if clients are stateless and have no way to know a response needs to be canceled after a restart.
  • Adding a separate proxy that sends heartbeats while holding the foreground LocalAI request open, but it adds significant complexity and risk, and at this point it's silly not to try to upstream the fix first.

Additional context

SSE comments are intended for connection keepalives and should be ignored by conforming clients. Making the feature opt-in would avoid compatibility problems with clients that parse SSE imperfectly.

The heartbeat writer should be serialized with normal stream writes, stop on cancellation or write failure, and preferably stop once the first real event is emitted.

Lenguaje dominante
Go
Estrellas
49.2k
Forks
4.5k
Merge medio
1 d 7 h
PR fusionados (30 d)
362

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 mudler/LocalAI

Todos los issues de mudler/LocalAI

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.