Intermittent ReadFile stalls after guest idle — not reproduced, bisector included

Abierto
  • ¿Algo no está bien?
#73 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
28/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
go, grpc
Área
distributed-systems, observability

Línea de trabajo

Review the capture tooling under .specs/tools/, especially wedge and e03probe, and use their documented probe modes to understand the existing measurements. A useful outcome would be a reproducible stall with receiver-side latency distributions or a clear pointer to existing guest-read instrumentation; the issue does not define a specific code change.

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

Descripción

question
Summary

On a self-hosted single-node k3s deployment I've observed intermittent multi-second (at times tens of seconds) ReadFile latency on paths that had been reading normally moments earlier. Occurrences correlate loosely with guest inactivity. Working hypothesis class: a wake-up path — suspended guest or idle connection state — blocking on the read. I have not been able to reproduce it under controlled conditions, so I'm filing this for visibility with capture tooling attached, rather than a speculative fix.

Investigation to date

Probes driven by a purpose-built bisector against a real router + guest:

Probe Result
Missing-path reads, cold and warm NotFound in ~25 ms, no stalls
Sequential read load (150 ops) clean
Forced suspend → immediate warm read guest auto-resumed; read completed in 185 ms
Composite (follow-stream + poller + mid-run suspend) 60/60 reads clean
Asks
  1. Has anyone observed multi-second ReadFile stalls correlated with guest idle or suspend/resume?
  2. Is there existing latency instrumentation on the guest read path (metrics or trace spans) that could confirm or refute wake-up attribution? If yes, pointers appreciated. If not, that instrumentation may be worth adding independently — it would turn the next occurrence into evidence rather than anecdote.
  3. If it recurs on our side, I'll attach receiver-side latency distributions captured with the tooling below.
Capture tooling

Available on fork branch barceloneta-k3s under .specs/tools/:

  • wedge — targeted bisector: segment-read patterns (s1/s2/s3), plus getenv, suspend, warm-hang, load, soak modes
  • e03probe — transcript-egress latency probe: follow-stream vs polling vs segmented reads, plus microbenchmarks (shell echo round-trip, StartProcess → first chunk, ReadFile at 4 KB / 256 KB / 1 MB)

Both emit JSON lines on stdout, so runs are directly diffable.

Environment
  • Single-node k3s; guests exercised both run-to-completion and under suspend/resume
  • Standard client → api → router → guest gRPC path
Lenguaje dominante
Go
Estrellas
70
Forks
17
Merge medio
21 h 36 min
PR fusionados (30 d)
19

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 agent-substrate/env

Todos los issues de agent-substrate/env

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.