Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#1,326 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
go
Bereich
backend

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Go
Sterne
115
Forks
14
Ø Merge
9 Std. 44 Min.
Gemergte PRs (30 T.)
775

Entwicklungsumgebung

Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Agent-Field/CodeAF

Alle Issues in Agent-Field/CodeAF

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.