fix(observability): pin one telemetry snapshot per Logs and Trace response
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
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- go
- Área
- observability-sre
Línea de trabajo
Start by locating the Logs and Trace response entry points and the existing telemetry statement/index, cache-acknowledgement, and contribution reads. Add deterministic tests that publish, compact, or retain telemetry between response stages, then verify one file set across entries, counts, and trace/log sections; also check cancellation cleanup, publisher progress, and the native and race suites.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The whole-PR review of #272 identified a low-severity, pre-existing response consistency gap outside its five inline findings: https://github.com/labstack/fanout/pull/272#pullrequestreview-5386440469 .
Logs queries entries and histogram separately. Trace queries a candidate, reads its index, and fetches related logs in separate snapshots. A telemetry publication between those operations can make sections of the same response describe different active file sets.
Pin one bounded telemetry snapshot for every statement/index read that contributes to a single Logs or Trace response. Read cache acknowledgements and contributions transactionally under that snapshot; preserve immediately visible uncached files, exact clipped windows, redaction, cancellation and publisher progress. Define transaction/lock ownership once rather than adding retries or snapshot fallbacks.
Acceptance: deterministic tests publish, compact or retain telemetry between response stages and prove entries/counts and trace/log sections describe one file set. Cancellation releases all resources; publishers still progress under the existing reader grace period; the full native and race suites pass.
- Lenguaje dominante
- HTML
- Estrellas
- 6
- Forks
- 0
- Merge medio
- 2 h 25 min
- PR fusionados (30 d)
- 25
Preparar el entorno
- Incluye un Dockerfile o un 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 labstack/fanout
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 42/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
Todos los issues de labstack/fanout
Issues similares
-
bug effort:low model:light plan planner:opus-5-5
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
open-telemetry/opentelemetry-python-genai#895 ·
Los mantenedores suelen responder en 1 día
-
Status: New
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
dnnsoftware/Dnn.Platform#7556 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Improvement Python Spans
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
getsentry/sentry-python#7994 · 1 comentario ·
Los mantenedores suelen responder en 1 día