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

standing: a firing's tasks board is always empty — wrong task index path + armed-firing scoping hide project tasks

Abierto
  • ¿Algo no está bien?
#1,326 0 comentarios 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
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend

Línea de trabajo

Start with internal/session/task_index.go:404, internal/session/standing_run.go:940-941, internal/session/tools_tasks.go:935, and internal/session/taskdelta.go:721. Reproduce a standing item that calls tasks, checking unarmed and armed firings plus id and scope=everywhere queries. Done means standing firings can see project tasks and eligible tasks in other windows through the promised task-tool paths.

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

Descripción

area:session bug sev:serious

A standing-run firing that calls the tasks tool always sees an empty board, regardless of whether project tasks exist. Two independent root causes, both in internal/session, produce this: the task index file resolves to a wrong path for standing runs (cause A, bites unarmed firings), and an armed firing's task scoping hides project tasks behind graph-child-only lookups (cause B, bites the observed firing).

Reproduction

Create a standing item whose body calls tasks (with or without an id or scope argument) every 20 minutes. For example, a kind=task item monitoring three delegated tasks (ids 4, 5, 6) in the conversation that created the item. When the firing runs, every variant returns empty:

  • No-query listing: "No tasks have run in this project yet."
  • scope=everywhere: equally empty.
  • Id lookups: No task "4" among the pieces you handed out.

...while those tasks are live and visible in the conversation that created the standing item.

Root causes

A -- Wrong task index path (task_index.go:404)

taskIndexFile() at internal/session/task_index.go:404 (filepath.Dir at :406) derives the index bucket as filepath.Dir(Place.Dir). For a normal conversation, Place.Dir is a session folder under ~/.codeaf/v3/projects/<workspace-hash>/, so one Dir() hop resolves to the correct project bucket. For a standing firing, Place.Dir is ~/.codeaf/v3/standing/<item-id>/runs/0001 (set at standing_run.go:773,778), so one hop lands in runs/ and ReadTaskIndex opens a tasks.jsonl that never exists there.

Cause A bites any standing firing whose taskRows() reaches TaskIndex() -- that is, when taskID == 0. For the observed armed firing (taskID != 0), cause B below was the active mechanism.

B -- Armed-firing scoping hides project tasks (standing_run.go:941, tools_tasks.go:935, taskdelta.go:721)

standingWideWork at internal/session/standing_run.go:940-941 arms the firing by setting cfg.taskID (and cfg.tasker) when the item divides (swarm on, brief passes the width gate at :884). With taskID != 0, taskRows() at internal/session/tools_tasks.go:935 returns only the root node's graph children -- which for a standing firing that has not divided is an empty slice -- and never calls TaskIndex() at all. Separately, tellsElsewhere() at internal/session/taskdelta.go:721 returns false when InTask || taskID != 0 (:722), preventing the scope=everywhere path from reaching taskElsewhereText (tools_tasks.go:256, gated at :260/268). Together these mean an armed firing cannot see conversation tasks by id, by query, or by any scope.

Why this is a bug, not intentional scoping

task_index.go:40-56 header comment states the scope is the project, not the conversation. The tasks tool contract (tasksDescription at internal/session/tools_tasks.go:72) promises that other windows' live work appears as anonymous "another window" rows. Both promises are broken for standing firings: project tasks are invisible, and live tasks in other windows never appear.

Suggested fix directions

Three changes needed:

  1. Fix the index path (cause A). Derive the project bucket for standing runs directly instead of filepath.Dir(Place.Dir) -- for example, walk Place.Dir upward until the tasks.jsonl or the project bucket marker is found.

  2. Do not arm with an unmatchable taskID (cause B). Leave cfg.taskID at 0 for standing firings so taskRows() falls through to TaskIndex(). This alone does not work without fix 1.

  3. Let tellsElsewhere() return true for standing runs (or add a standing-specific path) so that scope=everywhere works.

Fix 1 alone does not cure cause B (an armed firing never reaches the index). Fix 2 alone (using fix 1's corrected index) is the full cure for both unarmed and armed firings but depends on fix 1. Fix 3 is independent of 1 and 2 and covers the elsewhere gate.

Workaround

Replace the kind=task standing item with a kind=probe item whose shell command greps the project's real tasks.jsonl directly at ~/.codeaf/v3/projects/<workspace-hash>/tasks.jsonl.

—

Drafted with CodeAF · reviewed and owned by the author

Lenguaje dominante
Go
Estrellas
115
Forks
14
Merge medio
9 h 37 min
PR fusionados (30 d)
755

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 Agent-Field/CodeAF

Todos los issues de Agent-Field/CodeAF

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.