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

[BUG] Stall detection cannot see a session idling inside a tool call: pane-log re-arm keeps the grace alive through `sleep`

Abierto
  • ¿Algo no está bien?
#680 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
devtools, observability

Línea de trabajo

Empieza por generic.py, alrededor de _log_activity_key, el bucle de fecha límite de stall cerca de la línea 811 y _sample_weighted_usage cerca de la línea 1154; después inspecciona policy.py para ver la configuración de stall y las superficies de TUI/journal. Compara el crecimiento de la transcripción en vivo con la actividad del pane-log y define cómo deben registrarse y mostrarse los periodos de inactividad sin tratar cada llamada de herramienta larga como un stall; se considera terminado cuando el tramo de inactividad es visible en el run record, el journal y la TUI.

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

Descripción

area:adapters area:tui enhancement needs-design P3
Description

_log_activity_key re-arms dev_stall_grace_s from the tee'd pane log's (mtime_ns, size). A coding CLI repaints its spinner every second while it is blocked inside a tool call, so the pane log grows the whole time. The grace therefore cannot expire while a session sits in sleep, and a session that keeps its turn alive by polling — sleep 590; cat <background-task-output> — is indistinguishable from one streaming a diff.

Nothing in the run record separates the two. nudges stays 0, the heartbeat stays fresh, session-start is the last journal event, and the TUI shows a working session. The only bound is session_timeout_min.

This is the shape #157 named but did not file: "because the session never ends a turn, it never emits a result-less Stop, so dev_stall_grace_s / dev_stall_nudges never engage." #157 asked for prompt teardown once timeout_s fires. This asks for the gap before that: for the hours in between, the orchestrator has no signal at all.

Why sessions do this now. #109 / PR #122 ship CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 to stop a session yielding its turn to a background subagent. That removed the sanctioned path but not the incentive: there is still no background-completion re-invocation, so yielding costs a 600 s grace plus a nudge that is itself a submitted turn (dev_stall_nudges_cap, #149). Waiting in-band with sleep is cheaper for the session — and it is the one shape no detector sees. The guard did not remove the wait; it moved the wait somewhere invisible.

Steps to reproduce
  1. Claude adapter, stock profile (so CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 is set), dev_stall_grace_s = 600.
  2. Run a story whose dev session spawns a subagent and then polls for its result rather than doing the work inline — e.g. sleep 590; cat <task-output-file>, repeated. 590 s is the longest sleep that fits one Bash call, whose timeout caps at 600000 ms.
  3. Watch bmad-loop tui and the journal.
Expected behavior

Time a session spends idle inside a tool call is visible. At minimum the run record should let an operator answer "how much of this session's wall clock was spent doing nothing", and the TUI should not present such a session identically to a working one.

Actual behavior

The session reads as healthy for as long as it likes. stall_nudges_sent stays 0 because the grace deadline is pushed forward by every spinner repaint. No journal event marks the idle stretch. session_timeout_min is the only backstop, and it fires on total elapsed time, not on idleness.

Operator-side measurement over two runs on 0.11.0 (Claude adapter, macOS): one review session spent 44.2 of 64.2 minutes in sleep, another 17.0 of 31.8, and one dev session 90 of 107 minutes — 84%. Three single-subagent spawns accounted for 80% of that dev session's sleep; fan-outs amortise one wait across several agents and cost little. Four of seven sessions in the same runs never slept at all, including one that drove 22 subagents through 87 minutes, so this is session improvisation the loop currently permits rather than a deterministic path. Those runs are on a different machine from the checkout these line references were read on, so the numbers are quoted as operator measurements rather than attached artifacts. The run directories still exist and I can pull the journals or a diagnose dump if that would help. The code-level argument above stands on its own either way.

Suggested direction

The adapter already holds what it needs. transcript_path arrives on the first hook event and _sample_weighted_usage already polls that live file mid-turn for token spend. A session inside sleep appends no transcript entries and its weighted usage does not move, while the pane log keeps growing — so the two signals disagree exactly when the session is idle.

Worth separating, because they differ in risk:

  1. Observability (low risk). Track time since the last transcript append alongside the pane-log key. Surface it in the TUI and journal an event when it crosses a threshold. This alone turns an invisible 90 minutes into a visible one and costs nothing in false stalls.
  2. Bounding (needs design). Do not simply stall on absent transcript growth — a legitimately long single tool call looks the same (#157's 59-minute docker run is the counter-example). If a bound is wanted it needs its own knob and a way to tell a blocked tool call from a deliberate poll.

The upstream shape behind all of it — no background-completion re-invocation — is noted for context, not proposed here. As long as it is absent, sessions have a standing incentive to wait in-band, and item 1 at least makes the cost measurable.

Filing this separately from #109 because that issue's resolution is shipped and works for what it targeted; this is the pressure that moved elsewhere afterwards.

Which area is this for?

Orchestrator / control loop

bmad-loop Version

0.11.0

Which coding CLI are you using?

Claude (claude)

Operating System

macOS

Relevant log output
generic.py:971  _log_activity_key -> (st.st_mtime_ns, st.st_size) of logs_dir/<task_id>.log
generic.py:811  key = self._log_activity_key(...); if key != last_activity: stall_deadline = now + grace
generic.py:1154 _sample_weighted_usage(transcript_path, spec)   # live transcript already polled mid-turn
policy.py:104   dev_stall_grace_s = 600
policy.py:122   dev_stall_nudges_cap = 6
Confirm
  • I've searched for existing issues (#109, #149, #157, #158, #470 are related; none covers in-tool idle detection)
  • I'm using the latest version
Lenguaje dominante
Python
Estrellas
146
Forks
68
Merge medio
2 d 12 h
PR fusionados (30 d)
41

Preparar el entorno

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 bmad-code-org/bmad-loop

Todos los issues de bmad-code-org/bmad-loop

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.