johno/beads
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update issues database

Browse Source 
Amp-Thread-ID: https://ampcode.com/threads/T-d5fb1beb-0350-4a49-b8fa-ab752a82ef8e
Co-authored-by: Amp <amp@ampcode.com>
This commit is contained in:
Steve Yegge
2025-10-18 09:05:05 -07:00
parent 7cbc130fd7
commit 5f199a6c71
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.beads/issues.jsonl
View File

@@ -52,9 +52,9 @@
{"id":"bd-163","title":"Test A","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-10-17T23:06:59.59343-07:00","updated_at":"2025-10-17T23:06:59.740704-07:00","closed_at":"2025-10-17T23:06:59.740704-07:00","dependencies":[{"issue_id":"bd-163","depends_on_id":"bd-164","type":"blocks","created_at":"2025-10-17T23:06:59.668292-07:00","created_by":"daemon"}]}
{"id":"bd-164","title":"Test B","description":"","status":"closed","priority":2,"issue_type":"task","created_at":"2025-10-17T23:06:59.626612-07:00","updated_at":"2025-10-17T23:06:59.744519-07:00","closed_at":"2025-10-17T23:06:59.744519-07:00"}
{"id":"bd-165","title":"bd ready doesn't show epics/tasks ready to close when all children complete","description":"The 'bd ready' command doesn't show epics that have all children complete as ready work. Example: vc-30 (epic) blocks 4 children - 3 are closed, 1 is in_progress. The epic itself should be reviewable/closable but doesn't show in ready work. Similarly, vc-61 (epic, in_progress) depends on vc-48 (closed) but doesn't show as ready. Expected: epics with all dependencies satisfied should show as ready to review/close. Actual: 'bd ready' returns 'no ready work' even though multiple epics are completable.","acceptance_criteria":"bd ready shows epics/tasks that have all dependencies satisfied (even if status is in_progress), allowing user to review and close them","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-10-18T00:04:41.811991-07:00","updated_at":"2025-10-18T00:20:36.188211-07:00","closed_at":"2025-10-18T00:20:36.188211-07:00"}
{"id":"bd-167","title":"CleanupStaleInstances() never called in production - orphaned claims accumulate","description":"The CleanupStaleInstances() method exists in storage layer but is never called in production code. This means dead executors leave orphaned claims that block work forever. Example: vc-106 claimed by executor that died 2 hours ago, still shows in_progress with execution_state record. Need to: 1) Add periodic cleanup to executor main loop (every 5 min?), 2) Make cleanup also release claimed issues (delete execution_state AND reset status to open), 3) Add comment explaining why released.","design":"Add background goroutine in executor that calls CleanupStaleInstances() every 5 minutes. When marking instance stopped, also query for all issues claimed by that instance and release them (delete execution_state, set status=open, add event comment).","acceptance_criteria":"Dead executors automatically release their claims within 5-10 minutes of going stale, issues return to open status and become available for re-execution","status":"open","priority":0,"issue_type":"bug","created_at":"2025-10-18T00:24:57.920072-07:00","updated_at":"2025-10-18T00:24:57.920072-07:00"}
{"id":"bd-168","title":"releaseIssueWithError() deletes execution_state but leaves status as in_progress","description":"When an executor hits an error and releases an issue via releaseIssueWithError(), it deletes the execution_state but leaves the issue status as in_progress. This means the issue drops out of ready work but has no active executor. Expected: releasing should reset status to open so the issue becomes available again. Current code in conversation.go just calls ReleaseIssue() which only deletes execution_state.","design":"Update releaseIssueWithError() to also update issue status back to open. Or create a new ReleaseAndReopen() method that does both atomically in a transaction.","acceptance_criteria":"Issues released due to errors automatically return to open status and show in bd ready","status":"open","priority":1,"issue_type":"bug","created_at":"2025-10-18T00:25:06.798843-07:00","updated_at":"2025-10-18T00:25:06.798843-07:00"}
{"id":"bd-169","title":"Add 'bd stale' command to show orphaned claims and dead executors","description":"Need visibility into orphaned claims - issues stuck in_progress with execution_state but executor is dead/stopped. Add command to show: 1) All issues with execution_state where executor status=stopped or last_heartbeat \u003e threshold, 2) Executor instance details (when died, how long claimed), 3) Option to auto-release them. Makes manual recovery easier until auto-cleanup (bd-167) is implemented.","design":"Query: SELECT i.*, ei.status, ei.last_heartbeat FROM issues i JOIN issue_execution_state ies ON i.id = ies.issue_id JOIN executor_instances ei ON ies.executor_instance_id = ei.instance_id WHERE ei.status='stopped' OR ei.last_heartbeat \u003c NOW() - threshold. Add --release flag to auto-release all found issues.","acceptance_criteria":"bd stale shows orphaned claims, bd stale --release cleans them up","status":"open","priority":1,"issue_type":"feature","created_at":"2025-10-18T00:25:16.530937-07:00","updated_at":"2025-10-18T00:25:16.530937-07:00"}
{"id":"bd-167","title":"CleanupStaleInstances() never called in production - orphaned claims accumulate","description":"The CleanupStaleInstances() method exists in storage layer but is never called in production code. This means dead executors leave orphaned claims that block work forever. Example: vc-106 claimed by executor that died 2 hours ago, still shows in_progress with execution_state record. Need to: 1) Add periodic cleanup to executor main loop (every 5 min?), 2) Make cleanup also release claimed issues (delete execution_state AND reset status to open), 3) Add comment explaining why released.","design":"Add background goroutine in executor that calls CleanupStaleInstances() every 5 minutes. When marking instance stopped, also query for all issues claimed by that instance and release them (delete execution_state, set status=open, add event comment).","acceptance_criteria":"Dead executors automatically release their claims within 5-10 minutes of going stale, issues return to open status and become available for re-execution","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-10-18T00:24:57.920072-07:00","updated_at":"2025-10-18T02:09:05.05969-07:00","closed_at":"2025-10-18T02:09:05.05969-07:00"}
{"id":"bd-168","title":"releaseIssueWithError() deletes execution_state but leaves status as in_progress","description":"When an executor hits an error and releases an issue via releaseIssueWithError(), it deletes the execution_state but leaves the issue status as in_progress. This means the issue drops out of ready work but has no active executor. Expected: releasing should reset status to open so the issue becomes available again. Current code in conversation.go just calls ReleaseIssue() which only deletes execution_state.","design":"Update releaseIssueWithError() to also update issue status back to open. Or create a new ReleaseAndReopen() method that does both atomically in a transaction.","acceptance_criteria":"Issues released due to errors automatically return to open status and show in bd ready","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-10-18T00:25:06.798843-07:00","updated_at":"2025-10-18T02:09:08.595764-07:00","closed_at":"2025-10-18T02:09:08.595764-07:00"}
{"id":"bd-169","title":"Add 'bd stale' command to show orphaned claims and dead executors","description":"Need visibility into orphaned claims - issues stuck in_progress with execution_state but executor is dead/stopped. Add command to show: 1) All issues with execution_state where executor status=stopped or last_heartbeat \u003e threshold, 2) Executor instance details (when died, how long claimed), 3) Option to auto-release them. Makes manual recovery easier until auto-cleanup (bd-167) is implemented.","design":"Query: SELECT i.*, ei.status, ei.last_heartbeat FROM issues i JOIN issue_execution_state ies ON i.id = ies.issue_id JOIN executor_instances ei ON ies.executor_instance_id = ei.instance_id WHERE ei.status='stopped' OR ei.last_heartbeat \u003c NOW() - threshold. Add --release flag to auto-release all found issues.","acceptance_criteria":"bd stale shows orphaned claims, bd stale --release cleans them up","status":"closed","priority":1,"issue_type":"feature","created_at":"2025-10-18T00:25:16.530937-07:00","updated_at":"2025-10-18T02:09:12.529064-07:00","closed_at":"2025-10-18T02:09:12.529064-07:00"}
{"id":"bd-17","title":"bd should auto-detect .beads/*.db in current directory","description":"When bd is run without --db flag, it defaults to beads' own database instead of looking for a .beads/*.db file in the current working directory. This causes confusion when working on other projects that use beads for issue tracking (like vc).\n\nExpected behavior: bd should search for .beads/*.db in cwd and use that if found, before falling back to default beads database.\n\nExample: Running 'bd ready' in /Users/stevey/src/vc/vc/ should automatically find and use .beads/vc.db without requiring --db flag every time.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-10-16T20:46:08.971822-07:00","updated_at":"2025-10-17T01:32:00.650584-07:00","closed_at":"2025-10-16T10:07:34.046944-07:00"}
{"id":"bd-18","title":"Document or automate JSONL sync workflow for git collaboration","description":"When using beads across multiple machines/environments via git, there's a workflow gap:\n\n1. Machine A: Create issues → stored in .beads/project.db\n2. Machine A: bd export -o .beads/issues.jsonl\n3. Machine A: git add .beads/issues.jsonl \u0026\u0026 git commit \u0026\u0026 git push\n4. Machine B: git pull\n5. Machine B: ??? issues.jsonl exists but project.db is empty/stale\n\nThe missing step is: bd import --db .beads/project.db -i .beads/issues.jsonl\n\nThis needs to be either:\na) Documented clearly in workflow docs\nb) Automated (e.g., git hook, or bd auto-imports if jsonl is newer than db)\nc) Both\n\nReal-world impact: User had Claude Code on GCP VM create vc issues from BOOTSTRAP.md. They were exported to issues.jsonl and committed. But on local machine, vc.db was empty until manual import was run.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-10-16T20:46:08.971822-07:00","updated_at":"2025-10-17T01:32:00.651438-07:00","closed_at":"2025-10-14T02:51:52.199766-07:00"}
{"id":"bd-19","title":"Root issue for dep tree test","description":"","status":"closed","priority":1,"issue_type":"task","created_at":"2025-10-16T20:46:08.971822-07:00","updated_at":"2025-10-17T01:32:00.652067-07:00","closed_at":"2025-10-16T10:07:34.1266-07:00"}