Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,326 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Go
Star
115
Fork
14
Merge trung bình
9 giờ 37 phút
Pull request đã merge (30 ngày)
755

Chuẩn bị môi trường

Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Agent-Field/CodeAF

Tất cả issue của Agent-Field/CodeAF

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.