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

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:

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