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

SessionProcessor closure state claims session-scope but resets per-step (warning false-positive + doom-loop detector silently degraded)

Ouverte
  • Quelque chose ne va pas ?
#889 1 commentaire 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
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Calme
Stack technique
typescript
Domaine
backend

Piste de recherche

Commencez par auditer les variables de fermeture dans processor.ts:43, 57 et 207-219, puis suivez SessionProcessor.create() et la boucle par étape dans session/prompt.ts:485. Déterminez quel état est propre à chaque étape et lequel s’applique à toute la session, ajoutez la couverture de régression décrite dans les critères d’acceptation et vérifiez que le comportement de l’avertissement et du doom-loop entre les tours correspond à leur portée prévue.

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

Description

bug

Symptom

State declared in SessionProcessor.create()'s closure scope is documented as "session-scoped, accumulates across process() invocations within a session" (see processor.ts:207-210), but loop() in session/prompt.ts:485 creates a fresh SessionProcessor every step. The closure variables therefore reset on each step, not each session.

This is a documentation/implementation mismatch — the comments describe an intent that the code does not deliver.

Known victims

  1. plan_no_tool_generation warning — sessionToolCallsMade (processor.ts:57). On a multi-step plan session that runs tools across early steps and produces a final text-only step, the warning fires on the last step even though the agent did its job correctly. Patched as a targeted workaround in #888 (PR for #887) by also scanning streamInput.messages for prior assistant tool-call content at warning-evaluation time. Not a structural fix.

  2. Doom-loop detector — toolCallCounts (processor.ts:43, used in 207-219). The comment explicitly states "cross-turn accumulation catches slow-burn loops that stay under the threshold per-turn but add up over the session" — but because the counter resets per step, slow-burn loops that cross step boundaries cannot trigger the threshold. The detector still catches within-step hot loops (e.g. todowrite 2,080x in a single step) and is presumably what saved us from realising sooner, but the documented cross-turn behavior is broken. Unpatched in #888.

There may be other consumers of the same closure variables (e.g. toolcalls map at line 41) where per-step vs session scoping matters for correctness — worth an audit.

Proper fix (options)

The targeted workaround in #888 only addresses victim 1, and only by reading from the conversation history (which the warning happens to have access to). It does not generalize to the doom-loop detector, whose state has no equivalent representation in the message stream.

  1. Move SessionProcessor.create() outside the per-step while (true) body in loop() so a single processor instance handles all steps of a session. This is the change that most closely matches the comments' intent. Risk: anything else in create()'s closure that should be per-step would silently break. Needs an audit of all closure variables before flipping.

  2. Lift the two affected counters to a session-keyed Map<sessionID, …> at module scope. Smaller blast radius than #1, but adds memory-leak surface (need explicit cleanup when sessions end / abort).

  3. Keep the per-step semantics and update the comments + variable names to match reality. Then re-derive the cross-turn doom-loop signal from the message stream the same way the plan-no-tool workaround does (count tool-call content parts across the session). Risk: every consumer that thinks it's session-scoped has to be migrated individually.

I'd lean toward option 1 if the closure audit comes back clean. Otherwise option 3 is the safest; it doesn't pretend the bug is fixed and forces each consumer to make an explicit choice.

Acceptance criteria

  • Closure variables in SessionProcessor.create() are audited; each one is documented as either intentionally per-step or session-wide.
  • Variables that should be session-wide actually behave that way at runtime.
  • toolCallCounts cross-turn behavior matches its comment, OR the comment is rewritten to match the implementation.
  • plan_no_tool_generation warning is driven by whatever the canonical session-wide signal is (not the workaround scan added in #888).
  • Regression test for cross-turn doom-loop detection.
Langage dominant
TypeScript
Étoiles
810
Forks
121
Merge moyen
1 j 13 h
PR mergées (30 j)
64

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

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 AltimateAI/altimate-code

Toutes les issues de AltimateAI/altimate-code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

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