Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

internal/session: two tests fail only while other suites run beside them — a 40 ms wall-clock audit window, and a write under the home after Close

Ouverte
  • Quelque chose ne va pas ?
#1,491 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
go
Domaine
backend, testing-qa

Piste de recherche

Start with the two named tests in internal/session/task_settle_test.go and internal/session/retiredpin_wire_test.go, then reproduce them under the supplied GOMAXPROCS=2 busy-loop commands. Trace the audit-window behavior and Agent.Close lifecycle, including errand writers under <CODEAF_HOME>/v3. Done means both -count=200 loops pass under load three times, the post-Close home probe finds no late writes, and touched packages remain green without a rerun.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

area:session area:tests bug

What happened

Two internal/session tests fail only while other test suites run beside them on the same machine. Each passes when run alone. CLAUDE.md treats a failure like this as a bug report rather than a flake to rerun, so here it is. Both were seen during make pr-ready BASE=origin/dev runs for #1410 (santos/dev2) on 2026-09-24, and neither test file is touched by that branch. retiredpin_wire_test.go came to dev with #1108, and task_settle_test.go was last changed on dev in #949.

1. TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow (task_settle_test.go):

=== RUN   TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow
    task_settle_test.go:315: the report does not say what actually happened to the calls:
        the check ran out of time before a call could be made — it had 40ms
        Wrote greet.go with the greeting.
--- FAIL: TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow (0.75s)

The test sets config.auditWindow = 40 * time.Millisecond, a real wall-clock window, and scripts a checker that never answers on either of its two attempts. It expects the report to say the calls were abandoned. On a loaded box the 40 ms ran out before the first checker call was placed, so the report took the other true branch, "ran out of time before a call could be made". The assertion depends on the scheduler, not the code.

2. TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin (retiredpin_wire_test.go):

=== RUN   TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin
    testing.go:1464: TempDir RemoveAll cleanup: unlinkat /tmp/TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin1419077516/001/v3: directory not empty
--- FAIL: TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin (0.01s)

001 is the test's home.EnvVar directory. Something still writes under <home>/v3 after the test's agent.Close() cleanup has returned. The write races t.TempDir's RemoveAll, and it lands inside the removal only when the box is slow. The likely writer is the errand the test name refers to (a side call made beside the turn), or its journal, still running after Close. This is the same late-write-after-close class as #1198 and the cmd/codeaf hosted-welcome test (#1492). #1441 lists other load-only reds on the same branch; these two are not on it.

Replication

Deterministic (no model). Neither needs a key. Load the box, then loop the one test:

# load: one busy loop per core, stopped afterwards with `kill %1 %2 ...` or `pkill -x yes`
for i in $(seq "$(nproc)"); do yes >/dev/null & done
GOMAXPROCS=2 go test -count=200 -run '^TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow$' ./internal/session/
GOMAXPROCS=2 go test -count=200 -run '^TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin$' ./internal/session/

Without the load the same loops pass: 20 of 20 and 50 of 50 on both santos/dev2 and its base. The only sightings so far are one failure of each inside a whole make pr-ready (the light gate plus every package the branch touches, internal/session among them, run beside internal/tui3). How often the loaded loop above fails has not been measured yet; the first job of whoever takes this is to get it failing on demand.

Field. Not needed. No model is involved.

Where

  • internal/session/task_settle_test.go, TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow. Search for config.auditWindow = 40 * time.Millisecond. The two report sentences are checkerWindowClosed / "without answering and was abandoned" and "ran out of time before a call could be made".
  • internal/session/retiredpin_wire_test.go, TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin, together with whatever Agent.Close leaves running that writes under <CODEAF_HOME>/v3.

The fix

  1. The audit window in that test runs on the test's own clock, or the checker's first call is proven placed before the window is allowed to close, so the test asserts the stall sentence and never the scheduler.
  2. Agent.Close waits for everything it started that writes under the home, errands included, before it returns. This follows the close law #1259 and #1274 set for the process. After Close returns, nothing writes under the home. The test must not be changed to skip the cleanup.

Acceptance

  • Unit (under load): both -count=200 loops above are green with one busy loop per core running, three times in a row.
  • Unit (law): a probe that walks <home> for files modified after agent.Close() returned, after a 2-second wait, finds none for the talk-pin test's agent.
  • touched packages on the next promotion stays green without a rerun.
Langage dominant
Go
Étoiles
115
Forks
14
Merge moyen
12 h 24 min
PR mergées (30 j)
310

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Agent-Field/CodeAF

Toutes les issues de Agent-Field/CodeAF

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.