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

bd sync: 2025-11-23 19:58:20

Browse Source
This commit is contained in:
Steve Yegge
2025-11-23 19:58:20 -08:00
parent 21c331baee
commit 6222f970a6
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.beads/beads.jsonl
View File

@@ -169,7 +169,7 @@
{"id":"bd-5ki8","content_hash":"d89e5e528819934bcb7ee162fa7e32c27298db5816ecf51bcc8ede1809f1d5b9","title":"Add integration tests for adapter library","description":"Test suite for beads_mail_adapter.py covering all scenarios.\n\nAcceptance Criteria:\n- Test enabled mode (server available)\n- Test disabled mode (server unavailable)\n- Test graceful degradation (server dies mid-operation)\n- Test reservation conflicts\n- Test message sending/receiving\n- Mock HTTP server for testing\n- 90%+ code coverage\n\nFile: lib/test_beads_mail_adapter.py","notes":"Test suite completed with 29 comprehensive tests covering:\n- Enabled mode (server available): 10 tests\n- Disabled mode (server unavailable): 2 tests \n- Graceful degradation: 4 tests\n- Reservation conflicts: 2 tests\n- Configuration: 5 tests\n- Health check scenarios: 3 tests\n- HTTP error handling: 3 tests\n\n**Performance**: All tests run in 10ms (fast!)\n\n**Coverage highlights**:\n✅ Server health checks (ok, degraded, error, timeout)\n✅ All API operations (reserve, release, notify, check_inbox, get_reservations)\n✅ HTTP errors (404, 409 conflict, 500, 503)\n✅ Network errors (timeout, connection refused)\n✅ Malformed responses (bad JSON, empty body, plain text errors)\n✅ Environment variable configuration\n✅ Graceful degradation when server dies mid-operation\n✅ Conflict handling with both JSON and plain text errors\n✅ Dict wrapper responses ({\"messages\": [...]} and {\"reservations\": [...]})\n✅ Custom TTL for reservations\n✅ Default agent name fallback\n\nNo external dependencies, no slow integration tests, just fast unit tests with mocks.","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-07T22:43:21.294596-08:00","updated_at":"2025-11-08T01:32:39.906342-08:00","closed_at":"2025-11-08T01:32:39.906342-08:00","source_repo":".","dependencies":[{"issue_id":"bd-5ki8","depends_on_id":"bd-m9th","type":"blocks","created_at":"2025-11-07T22:43:21.296024-08:00","created_by":"daemon"}]}
{"id":"bd-5otr","content_hash":"d08e4780fc80ffd39e678cab64038d50c31ccf842d2d9f4e6e598746324f2711","title":"Create startup hook snippet for upgrade detection","description":"Provide a reusable startup hook that agents can use to detect bd upgrades automatically.\n\n## What to Create\nA bash script snippet that:\n1. Reads current bd version\n2. Compares to last-seen version in metadata.json\n3. Shows 'bd info --whats-new' output when version changes\n4. Updates metadata.json with new version\n5. Auto-runs 'bd hooks install' if hooks outdated\n\n## Where to Document\n- Create examples/hooks/startup-version-check.sh\n- Document in AGENTS.md with usage instructions\n- Add comment header explaining how to integrate with Claude Code, Cursor, etc.\n\n## Key Features\n- Works today with zero bd code changes\n- Leverages existing bd info --whats-new\n- Uses metadata.json for persistence\n- Auto-fixes outdated git hooks\n\n## Acceptance Criteria\n- Script works standalone\n- Clear integration instructions for popular AI environments\n- Handles edge cases (no metadata.json, first run, etc.)\n","status":"closed","priority":1,"issue_type":"task","created_at":"2025-11-23T16:21:52.07179-08:00","updated_at":"2025-11-23T16:29:30.969796-08:00","closed_at":"2025-11-23T16:29:30.969796-08:00","source_repo":".","dependencies":[{"issue_id":"bd-5otr","depends_on_id":"bd-nxgk","type":"parent-child","created_at":"2025-11-23T16:21:52.073748-08:00","created_by":"daemon"}]}
{"id":"bd-5ots","content_hash":"0e91ce4af03138cc2f19c73535daddeb31fe3248e96c9ebaff5e9ff5895c9502","title":"SearchIssues N+1 query causes context timeout with GetLabels","description":"scanIssues() calls GetLabels in a loop for every issue, causing N+1 queries and context deadline exceeded errors when used with short timeouts or in-memory databases. This is especially problematic since SearchIssues already supports label filtering via SQL WHERE clauses.","status":"closed","priority":1,"issue_type":"bug","created_at":"2025-11-05T19:12:02.245879-08:00","updated_at":"2025-11-05T19:22:11.668682-08:00","closed_at":"2025-11-05T19:22:11.668682-08:00","source_repo":"."}
{"id":"bd-5qim","content_hash":"3e24a2f840b18191711da4184afb2efdd4508d39c750eeee38f583cde0e71712","title":"Optimize GetReadyWork performance - 752ms on 10K database (target: \u003c50ms)","description":"","notes":"# Performance Analysis (10K Issue Database)\n\nAnalyzed using CPU profiles from benchmark suite on Apple M2 Pro.\n\n## Operation Performance\n\n| Operation | Time | Allocations | Memory |\n|----------------------------------|---------|-------------|--------|\n| bd ready (GetReadyWork) | ~752ms | 167,466 | 16MB |\n| bd list (SearchIssues no filter) | ~11.6ms | 89,214 | 5.8MB |\n| bd list (SearchIssues filtered) | ~9.2ms | 62,365 | 3.5MB |\n| bd create (CreateIssue) | ~2.6ms | 146 | 8.6KB |\n| bd update (UpdateIssue) | ~0.32ms | 364 | 15KB |\n| bd close (UpdateIssue) | ~0.32ms | 364 | 15KB |\n\n**Target: \u003c50ms for all operations on 10K database**\n\n**Current issue: GetReadyWork is 15x over target (752ms vs 50ms)**\n\n## Root Cause\n\nGetReadyWork (internal/storage/sqlite/ready.go:90-128) uses recursive CTE to propagate blocking:\n- 65x slower than SearchIssues\n- Recalculates entire blocked issue tree on every call\n- Algorithm:\n 1. Find directly blocked issues via 'blocks' dependencies\n 2. Recursively propagate blockage to descendants (max depth: 50)\n 3. Exclude all blocked issues from results\n\n## CPU Profile Analysis\n\n- Database syscalls (pthread_cond_signal, syscall6): ~75%\n- SQLite engine overhead: inherent to recursive CTE\n- Application code (query construction): \u003c1%\n\n**Bottleneck is the recursive CTE query execution, not application code.**\n\n## Optimization Recommendations\n\n### High Impact (Likely to achieve \u003c50ms target)\n\n1. **Cache blocked issue calculation**\n - Add `blocked_issues` table updated on dependency changes\n - Trade write complexity for read speed (ready called \u003e\u003e dependency changes)\n - Eliminates recursive CTE on every read\n\n2. **Add/verify database indexes**\n ```sql\n CREATE INDEX IF NOT EXISTS idx_dependencies_blocked \n ON dependencies(issue_id, type, depends_on_id);\n CREATE INDEX IF NOT EXISTS idx_issues_status \n ON issues(status);\n ```\n\n### Medium Impact\n\n3. **Reduce allocations** (167K allocations for GetReadyWork)\n - Profile `scanIssues()` for object pooling opportunities\n - Reuse slice capacity for repeated calls\n\n### Low Impact (Not recommended)\n- Query optimization for CRUD operations (already \u003c3ms)\n- Connection pooling tuning (not showing in profiles)\n\n## Verification\n\nRun benchmarks to validate optimization:\n```bash\nmake bench-quick\ngo tool pprof -http=:8080 internal/storage/sqlite/bench-cpu-*.prof\n```\n\nProfile files automatically generated in `internal/storage/sqlite/`.","status":"in_progress","priority":0,"issue_type":"bug","created_at":"2025-11-14T09:02:46.507526-08:00","updated_at":"2025-11-23T19:53:15.532343-08:00","source_repo":"."}
{"id":"bd-5qim","content_hash":"d2afb78d684ca97e4b6f4d49a736538635107d70a630543c22da337d2dd46d01","title":"Optimize GetReadyWork performance - 752ms on 10K database (target: \u003c50ms)","description":"","notes":"# Performance Analysis (10K Issue Database)\n\nAnalyzed using CPU profiles from benchmark suite on Apple M2 Pro.\n\n## ✅ OPTIMIZATION COMPLETE\n\n**Current Performance (as of 2025-11-23):**\n- **10K database**: ~29ms (167K allocs, 16MB) ✅ **Target met!**\n- **20K database**: ~60ms (338K allocs, 53MB) - Acceptable for scale\n- **Original**: 752ms (before optimization)\n- **Improvement**: **25.8x faster** 🎉\n\n## Implementation\n\nThe cache optimization has been successfully implemented:\n\n1. ✅ **blocked_issues_cache table** (migration 015)\n - Materializes recursive CTE computation\n - Rebuilt on dependency/status changes\n - See: `internal/storage/sqlite/blocked_cache.go`\n\n2. ✅ **Cache invalidation triggers**\n - On dependency add/remove (`dependencies.go:156, 212`)\n - On status changes (`queries.go:521, 695`)\n - Only for 'blocks' and 'parent-child' dependency types\n\n3. ✅ **Database indexes verified**\n - `idx_dependencies_depends_on_type_issue`\n - `idx_dependencies_depends_on_type`\n - `idx_issues_status`\n - All recommended indexes in place\n\n## Benchmark Results\n\n```\nBenchmarkGetReadyWork_Large-10 (10K issues)\n 29ms per operation\n 167,447 allocations\n 15.9 MB allocated\n\nBenchmarkGetReadyWork_XLarge-10 (20K issues)\n 60ms per operation\n 337,819 allocations\n 53.4 MB allocated\n```\n\n## Original Performance Analysis\n\n| Operation | Time | Allocations | Memory |\n|----------------------------------|---------|-------------|--------|\n| bd ready (GetReadyWork) | ~752ms | 167,466 | 16MB |\n| bd list (SearchIssues no filter) | ~11.6ms | 89,214 | 5.8MB |\n| bd list (SearchIssues filtered) | ~9.2ms | 62,365 | 3.5MB |\n\n**Target: \u003c50ms for all operations on 10K database** ✅ **ACHIEVED**\n\n## Root Cause (Now Fixed)\n\nGetReadyWork originally used recursive CTE to propagate blocking on every call:\n- 65x slower than SearchIssues\n- Recalculated entire blocked issue tree on every call\n- Database syscalls: ~75% of CPU time\n\n## Solution\n\nCache-based approach implemented:\n- `blocked_issues_cache` table stores pre-computed blocked issues\n- Invalidated only when dependencies or issue status changes\n- Read queries use simple `NOT EXISTS` lookup instead of recursive CTE\n- Write complexity traded for read speed (ready called \u003e\u003e dependency changes)\n\n## Verification\n\nRun benchmarks to validate:\n```bash\ngo test -tags=bench -bench='BenchmarkGetReadyWork.*' -benchmem ./internal/storage/sqlite/\n```\n\nProfile files automatically generated in `internal/storage/sqlite/bench-cpu-*.prof`","status":"closed","priority":0,"issue_type":"bug","created_at":"2025-11-14T09:02:46.507526-08:00","updated_at":"2025-11-23T19:58:15.949755-08:00","closed_at":"2025-11-23T19:58:15.949755-08:00","source_repo":"."}
{"id":"bd-5xt","content_hash":"dc085d3c40802d0096d64c7953c846e8fd43fbeb23e45debeb614953fb0e67db","title":"Log errors from timer-triggered flushes instead of discarding","description":"","status":"closed","priority":3,"issue_type":"task","created_at":"2025-11-20T21:22:06.694953-05:00","updated_at":"2025-11-20T21:35:53.117434-05:00","closed_at":"2025-11-20T21:35:53.117434-05:00","source_repo":".","comments":[{"id":6,"issue_id":"bd-5xt","author":"stevey","text":"In FlushManager.run() at flush_manager.go:197-200, timer-triggered flushes silently discard errors:\n\n```go\ncase \u003c-fm.timerFiredCh:\n if isDirty {\n _ = fm.performFlush(needsFullExport) // ← Error discarded!\n```\n\nUsers won't know if auto-flush is failing. Should at minimum log errors.\n\nConsider:\n- Log error with debug.Logf() or fmt.Fprintf(os.Stderr)\n- Optionally expose flush status via a Status() method\n- Track last flush error for diagnostics\n\nRelated: Code review finding #4 from bd-52 race condition fix review.","created_at":"2025-11-21T02:22:16Z"}]}
{"id":"bd-6049","content_hash":"16c54bc547f4ab180aee39efbb197709a47a39047f5bc2dd59e6e6b57ca8bc87","title":"bd doctor --json flag not working","description":"The --json flag on bd doctor command doesn't produce JSON output. It continues to show human-readable output instead. The flag is registered locally on doctorCmd but the code uses the global jsonOutput variable set by PersistentPreRun. Need to investigate why the flag isn't being honored.","status":"closed","priority":2,"issue_type":"bug","created_at":"2025-11-02T17:08:18.170428-08:00","updated_at":"2025-11-02T18:41:01.376783-08:00","closed_at":"2025-11-02T18:41:01.376786-08:00","source_repo":".","comments":[{"id":15,"issue_id":"bd-6049","author":"stevey","text":"Fixed by removing the local --json flag definition in doctor.go that was shadowing the persistent --json flag from main.go. The doctor command now correctly uses the global jsonOutput variable.","created_at":"2025-11-24T03:31:11Z"}]}
{"id":"bd-6214875c","content_hash":"529bb1a17d8406422735bc89f38902b8c9dbecb7891c70921f3237de51465e53","title":"Split internal/rpc/server.go into focused modules","description":"The file `internal/rpc/server.go` is 2,273 lines with 50+ methods, making it difficult to navigate and prone to merge conflicts. Split into 8 focused files with clear responsibilities.\n\nCurrent structure: Single 2,273-line file with:\n- Connection handling\n- Request routing\n- All 40+ RPC method implementations\n- Storage caching\n- Health checks \u0026 metrics\n- Cleanup loops\n\nTarget structure:\n```\ninternal/rpc/\n├── server.go # Core server, connection handling (~300 lines)\n├── methods_issue.go # Issue operations (~400 lines)\n├── methods_deps.go # Dependency operations (~200 lines)\n├── methods_labels.go # Label operations (~150 lines)\n├── methods_ready.go # Ready work queries (~150 lines)\n├── methods_compact.go # Compaction operations (~200 lines)\n├── methods_comments.go # Comment operations (~150 lines)\n├── storage_cache.go # Storage caching logic (~300 lines)\n└── health.go # Health \u0026 metrics (~200 lines)\n```\n\nMigration strategy:\n1. Create new files with appropriate methods\n2. Keep `server.go` as main file with core server logic\n3. Test incrementally after each file split\n4. Final verification with full test suite","status":"closed","priority":1,"issue_type":"task","created_at":"2025-10-28T14:21:37.51524-07:00","updated_at":"2025-10-30T17:12:58.2179-07:00","closed_at":"2025-10-28T14:11:04.399811-07:00","source_repo":"."}