Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#1,366 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
cli, tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
115
Forks
14
Merge médio
13h 23min
PRs com merge (30d)
205

Preparar o ambiente

Ainda não verificamos os arquivos de configuração deste projeto. Comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Agent-Field/CodeAF

Todas as issues de Agent-Field/CodeAF

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.