Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Honor tail selection when container log capture starts asynchronously

Aperta
  • Qualcosa non va?
#305 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
docker, go, linux
Ambito
backend, observability

Direzione di ricerca

Start with internal/logs/containerlogs/container_logstreamer.go and pkg/io/tail_reader.go to trace how tail selection handles EOF while the capture file grows; compare the Docker and Podman capture entry points in internal/docker/cli_orchestrator.go and internal/podman/cli_orchestrator.go. First establish a reliable boundary between historical and live output, then cover delayed multi-batch history, follow and non-follow requests, preexisting captures, and independent consumers. Done means the requested history is returned without loss or duplication during follow mode.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

The first container log request can return more history than requested by tail=N because runtime capture starts asynchronously. This is a pre-existing V1 limitation also present in the V2 runtime-capture implementation under development in #295. Track it separately rather than expanding that PR.

Code context

The runtime capture is started with follow enabled:

CaptureContainerLogs(..., containers.StreamContainerLogsOptions{
    Follow: true,
    Timestamps: true,
})

Docker/Podman return after launching the capture process, before historical output is necessarily written. The response path immediately opens the capture file and applies:

if opts.Tail != nil {
    source = usvc_io.NewTailReader(source, int(*opts.Tail))
}

TailReader selects the last N lines at its first EOF and then delegates future reads directly to the underlying file. EOF on a still-growing capture file does not establish that runtime history has finished arriving. Relevant code: internal/logs/containerlogs/container_logstreamer.go, internal/docker/cli_orchestrator.go, internal/podman/cli_orchestrator.go, and pkg/io/tail_reader.go. V2's analogous path is internal/logs/v2containerlogs/container_logstreamer.go in #295.

Reproduction and evidence

A focused probe opened an empty capture with TailReader(..., 1), read its initial EOF, then appended the delayed historical batch:

first
second
third

Subsequent reads returned all three lines, not only third. That reproduces the reader behavior combined with the existing asynchronous capture contract; it is not an in-the-wild incident report. Prewarmed captures or synchronous simulated capture can hide the problem.

Expected behavior

The first request must honor the requested historical tail even when capture history arrives asynchronously. In follow mode, subsequent live lines should continue after that history, without loss or duplication. Non-follow requests should return the requested available history rather than depending on arbitrary scheduling delays.

Design constraints and validation

Establish a reliable history/live boundary before implementing the fix. Possibilities to evaluate include runtime-side tail selection and a finite historical capture followed by a well-defined live handoff; neither is chosen by this issue. A sleep or waiting for the first byte is not evidence that the entire history has arrived. Preserve shared-capture behavior and existing V1/V2 patterns.

Cover a first request against delayed, multi-batch history; follow and non-follow behavior; preexisting captures; and independent logical/physical consumers. Keep this work separate from watcher ordering, container lifecycle, and image pull policy changes.

Lingua principale
Go
Stelle
191
Fork
27
Merge medio
2g 9h
PR unite (30g)
16

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/dcp

Tutte le issue di microsoft/dcp

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.