cd0b16ca21
`gh api -i` exits code 1 on HTTP 304 responses, causing the catch blocks in checkPRListETag and checkCommitStatusETag to assume the resource changed and trigger unnecessary GraphQL batch queries every poll cycle. Fix: inspect stdout/stderr in the catch block for the 304 status line before falling back to "assume changed". Also unifies the 304 detection regex to handle HTTP/1.1, HTTP/2, and HTTP/2.0 status lines, and adds rateLimit introspection to the batch GraphQL query. Benchmark result (quiet-steady, 5 sessions, 15 min): - GraphQL points/hr: 260/5,000 (5%) — down from 820–1,416 pre-fix - ETag guard 304 rate: 100% - GraphQL batch calls during measurement: 0 Also fixes the benchmark harness to create placeholder tmux sessions with a claude symlink so the lifecycle actually polls sessions instead of short-circuiting to "killed". Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| test | ||
| .gitignore | ||
| CHANGELOG.md | ||
| package.json | ||
| tsconfig.json | ||