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

Document how to have read timeout be larger than idle timeout

Abierto
#425 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
go
Área
api, networking

Línea de trabajo

Comienza leyendo el punto de entrada de Reader y Conn.msgReader; después, revisa el issue 87 relacionado y el comportamiento de context mostrado en los ejemplos. Determina si la API actual puede admitir límites de tiempo separados para obtener un Reader y finalizar una lectura, y documenta el enfoque compatible o el cambio de diseño de API necesario.

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

Descripción

docs

Hi! Thanks for this excellent library.

I have a use case where I want the server to wait up to 10 seconds for the client to start sending data. If the server doesn't get a new Reader within that time, it closes the connection and bails.

However, if the client does start sending data, then they have a much longer time limit to finish sending. Say 2 minutes. As far as I can tell, there's not a good way to accomplish this with the current API design.

I saw this issue: https://github.com/nhooyr/websocket/issues/87

Which works IFF the idle timeout is larger than the read timeout.

This is because the Conn.msgReader holds on to the context passed in during Reader() Example:

ctx, cancel := context.WithTimeout(rootCtx, 10 *second)
defer cancel()

_, reader, err := ws.Reader(ctx)
if err != nil {
	// Err handling....
	log.Error(err)
	return
}

// If reading data takes longer than 10 seconds, the timeout above will fire, and the context will be cancelled
// Killing the connnection
data, err := io.ReadAll(reader)
if err != nil {
	// Err handling....
	log.Error(err)
	return
}

I can potentially work around this. Instead of using context.WithTimeout, I could just use context.WithCancel. Then have a time.AfterFunc(), which uses atomics to check if we got the reader already. In which case, don't cancel. Example:

ctx, cancel := context.WithCancel(rootCtx)
defer cancel()

gotReader := atomic.Bool{}

time.AfterFunc(10*time.Second, func() {
	if !gotReader.Load() {
		cancel()
	}
})

_, reader, err := ws.Reader(ctx)
if err != nil {
	// Err handling....
	log.Error(err)
	return
}
gotReader.Store(true)

time.AfterFunc(2*time.Minute, func() {
	cancel()
})

data, err := io.ReadAll(reader)
if err != nil {
	// Err handling....
	log.Error(err)
	return
}

I'm not sure what the best way to modify the API would be. You're unfortunately stuck with the io.Reader interface, without the ability to add a context. Thoughts?

Lenguaje dominante
Go
Estrellas
5.5k
Forks
377
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

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 coder/websocket

Todos los issues de coder/websocket

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.