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

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

Abierto
  • ¿Algo no está bien?
#889 1 comentario 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
backend

Línea de trabajo

Comienza auditando las variables de cierre en processor.ts:43, 57 y 207-219; después, sigue el flujo de SessionProcessor.create() y del bucle por paso en session/prompt.ts:485. Determina qué estado es por paso y cuál abarca toda la sesión, añade la cobertura de regresión descrita en los criterios de aceptación y verifica que el comportamiento de la advertencia y del doom-loop entre turnos coincida con el alcance previsto.

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

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
815
Forks
135
Merge medio
1 d 12 h
PR fusionados (30 d)
58

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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

Todos los issues de AltimateAI/altimate-code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.