Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#1,326 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Go
Estrelas
115
Forks
14
Merge médio
9h 44min
PRs com merge (30d)
775

Preparar o ambiente

Ainda não verificamos os arquivos de configuração deste projeto. Comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Agent-Field/CodeAF

Todas as issues de Agent-Field/CodeAF

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.