Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

An intention reported as an observation: a launcher's own line is not the run's

Abierto
  • ¿Algo no está bien?
#1,366 0 comentarios 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
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
go
Área
cli, tooling

Línea de trabajo

Start by locating the repository's background launchers, run logs, and waiting logic, then trace how launcher output is used to report completion. Compare the three described cases and decide whether launchers need externally readable refusal status and whether completion reports must include a fact produced by the run; done requires an agreed scope rather than a single fix.

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

Descripción

area:session bug sev:serious

A line that says work started is repeatedly read as a line that says work ran.
It is not the same statement, nothing in the output distinguishes them, and the
failing reading is the silent one.

The shape

When a run is started in the background, what comes back is the STARTER's
account of itself, not the run's. The only fact in it is the pid. Everything
else a reader takes from it is an assumption: that the process got the
resources it needed, that it reached the work, that the work produced anything.

This is the same family as one output with two meanings, with one difference
that makes it worse. There, two meanings share a channel and can be given
disjoint ranges. Here the two meanings are in DIFFERENT places: the intention
is in the launcher's output and the observation is in the run's own output, and
the failure is that the first is read where the second belongs.

WHY READING THE LINE CANNOT CATCH IT. "submitted", "started", "queued" and
"running" are all true of the launcher at the moment it prints them. There is
no wrong word to find. The line is accurate and the conclusion drawn from it is
not, which is why it survives review and survives being read again later.

Three sightings, all within about two days

A HEAVY SUITE THAT WAS REFUSED, REPORTED AS A SUITE THAT PASSED. A gate was
launched in the background, the lock was already held, and the wrapper refused
within a second. Its log said so in full, naming the holder and how to find it.
The launcher's own line said the run had started, that line was read, and the
gate was nearly reported as evidence. The refusal and the pass both leave a log.
Only one of them has numbers in it, and nothing but opening the log tells them
apart.

A CELL RUNNER LOGGING "submitted" OVER THREE IDLE PANES. Three cells sat at
$0.00 because a large brief never reached the composer. The runner's line was
true: it had submitted. Nothing downstream asked whether anything had been
received, and the run reported itself as dispatched for as long as it sat there.

A BACKGROUNDED SUITE WAITED ON BY MATCHING COMMAND TEXT. Two waiters looped on
a pattern that matched themselves and spun long after the work they were waiting
for had finished cleanly. The waiters' own output said they were waiting, which
was true, and said nothing about what they were waiting for.

A footnote of the same family, included because it shows the boundary: writing
a test file through a shell heredoc silently consumed every apostrophe in it,
so an assertion string ended early and the closing quote was eaten several lines
down. That one was caught by the compiler within seconds. It is a footnote and
not a finding for exactly that reason: something downstream checked. The three
above had nothing downstream that checked.

What actually separates the two

The test is whether the output contains a fact the WORK produced, as opposed to
a fact the thing that started the work produced. A package name and a duration
are the work's. A pid is the launcher's. "submitted" is the launcher's. An empty
log is neither, and in particular an empty log is not evidence of a quiet run:
a test runner prints nothing mid-package and a refusal prints everything at
once, so length says nothing about which happened.

Three habits that would have caught all three sightings, in order of how cheap
they are:

  1. NEVER QUOTE A BACKGROUNDED RUN UNTIL ITS OWN LOG CARRIES A LINE THE RUN
    WROTE. Not the launcher's line, not the log's existence, not its size.
  2. PROBE THE RESOURCE, NOT THE PROCESS. Whether a lock is held is a question the
    lock can answer. Whether a run is alive is not a question its command text
    can answer, because the text travels with every wrapper around it.
  3. A LAUNCHER THAT CAN REFUSE SHOULD MAKE THE REFUSAL IMPOSSIBLE TO MISS FROM
    THE OUTSIDE: a non-zero exit the caller can read without opening anything,
    in addition to the explanation in the log.

The third is the only one that is a code change, and it is the only one that
does not depend on whoever is reading remembering the rule. The first two are
habits, and a habit indexed under a verb fires only when somebody is already
thinking the right thought: the waiter defect happened because the rule about
not matching command text was filed under killing, and that reader was waiting.

What this is asking for

Not a single fix. A decision on whether launchers in this repository owe a
readable refusal, and whether anything that reports a run as done should be
required to carry a figure the run itself produced.

Lenguaje dominante
Go
Estrellas
115
Forks
14
Merge medio
9 h 38 min
PR fusionados (30 d)
749

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. 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-Field/CodeAF

Todos los issues de Agent-Field/CodeAF

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.