Summary
Some long-lived interactive GJC sessions repeatedly spawn:
gh pr view --json number,url
when the current branch has no PR (or the lookup fails). The repeated subprocesses consume most of one local CPU core while the session is otherwise idle.
Environment
- GJC
0.13.1 (latest release at reproduction time)
- WSL2, Linux kernel
6.18.33.2-microsoft-standard-WSL2
- 12 logical CPUs exposed to WSL
- Multiple interactive GJC sessions
Observed behavior
Two independent samples observed:
- 28 new
gh pr view --json number,url processes in 10 seconds
- 5 new processes in 10 seconds after the status-line configuration was changed, attributable to a long-lived session started before that change
A /proc/<pid>/stat sample over five 2-second windows showed affected GJC processes continuously consuming approximately 45–87% of one CPU core. Other GJC sessions started after removing the pr segment stayed around 1% while idle.
The current source appears to support a negative result in the instance cache (cachedPr === null), but the observed process churn indicates that the negative/in-flight cache is not durable across the actual long-lived render/config lifecycle in at least one path.
Expected behavior
- If the active status-line layout does not contain
pr, no PR lookup should run.
- A successful “no PR”, missing remote/default repo, timeout, and other lookup failures should have a bounded negative-cache TTL.
- At most one lookup should be in flight per repository/branch across status-line instances.
- Rendering should not directly create an unbounded sequence of network subprocesses.
Suggested fix
Use a process-level cache keyed by repository identity and branch, including:
- positive and negative entries with a bounded TTL;
- shared in-flight promise deduplication;
- invalidation on repository/branch change;
- an explicit guard that avoids lookup when the rendered segment set excludes
pr.
A regression test should repeatedly construct/render the status line with a null/failing lookup and assert that only one gh invocation occurs within the TTL.
Impact
With several sessions, this creates sustained CPU pressure and visible terminal/desktop lag. Repeated subprocess creation also adds avoidable pressure in WSL environments.
Summary
Some long-lived interactive GJC sessions repeatedly spawn:
when the current branch has no PR (or the lookup fails). The repeated subprocesses consume most of one local CPU core while the session is otherwise idle.
Environment
0.13.1(latest release at reproduction time)6.18.33.2-microsoft-standard-WSL2Observed behavior
Two independent samples observed:
gh pr view --json number,urlprocesses in 10 secondsA
/proc/<pid>/statsample over five 2-second windows showed affected GJC processes continuously consuming approximately 45–87% of one CPU core. Other GJC sessions started after removing theprsegment stayed around 1% while idle.The current source appears to support a negative result in the instance cache (
cachedPr === null), but the observed process churn indicates that the negative/in-flight cache is not durable across the actual long-lived render/config lifecycle in at least one path.Expected behavior
pr, no PR lookup should run.Suggested fix
Use a process-level cache keyed by repository identity and branch, including:
pr.A regression test should repeatedly construct/render the status line with a null/failing lookup and assert that only one
ghinvocation occurs within the TTL.Impact
With several sessions, this creates sustained CPU pressure and visible terminal/desktop lag. Repeated subprocess creation also adds avoidable pressure in WSL environments.