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

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

Aperta
  • Qualcosa non va?
#1,366 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
go
Ambito
cli, tooling

Direzione di ricerca

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.

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

Descrizione

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.

Lingua principale
Go
Stelle
115
Fork
14
Merge medio
9h 38m
PR unite (30g)
749

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 Agent-Field/CodeAF

Tutte le issue di Agent-Field/CodeAF

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.