fluentd log driver: default retry wait is passed in nanoseconds

Abierto
#5,320 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@ogulcanaydogan ya está trabajando en esto.

Desde el 2/11/2026.

  • #5321 de @ogulcanaydogan — abierto

Evaluación

Dificultad
1/5
Tiempo estimado
Menos de una hora
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
cli

Línea de trabajo

The bug is in pkg/logging/fluentd_logger.go, where defaultRetryWait is converted with int(defaultRetryWait) instead of milliseconds, and the existing tests in the same package assert that wrong value. Start by reading how retryWait feeds the fluent-logger Config and the fluentd-retry-wait handling that already uses Milliseconds(). Done means the default is passed in milliseconds and the tests check that value. Pull request #5321 is already open against this issue, so check it before starting.

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

Descripción

In pkg/logging/fluentd_logger.go the default is defaultRetryWait = 1000 * time.Millisecond and retryWait := int(defaultRetryWait), which is 1000000000. fluent-logger-golang reads Config.RetryWait as milliseconds, and the code already converts a user-set fluentd-retry-wait with temp.Milliseconds().

Without fluentd-retry-wait the logger therefore gets about 11 days of retry wait. Its backoff caps the wait at MaxRetryWait (60000 ms), so a reconnect waits a minute instead of the intended one second.

Using defaultRetryWait.Milliseconds() fixes it. The existing tests compared against int(defaultRetryWait), so they matched the bug. I have a patch that changes them to check the value in milliseconds.

Lenguaje dominante
Go
Estrellas
10.5k
Forks
839
Merge medio
3 d 18 h
PR fusionados (30 d)
40

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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 containerd/nerdctl

Todos los issues de containerd/nerdctl

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.