Skip to content

fix(build-executor): release build log buffers on the cache-hit cleanup path (Closes #107) - #167

Open
SakethSumanBathini wants to merge 1 commit into
harsharajkumar-273:mainfrom
SakethSumanBathini:fix/107-buildlogs-leak-on-cache-hit
Open

fix(build-executor): release build log buffers on the cache-hit cleanup path (Closes #107)#167
SakethSumanBathini wants to merge 1 commit into
harsharajkumar-273:mainfrom
SakethSumanBathini:fix/107-buildlogs-leak-on-cache-hit

Conversation

@SakethSumanBathini

Copy link
Copy Markdown
Contributor

Closes #107

I've left a comment on #107 with the full trace. Short version: the sessions Map named in the issue is already cleaned up, but there is a real unbounded-growth bug four lines away, and this PR fixes that one.

Why the stated diagnosis no longer holds

Traced against main @ 2f06e6e:

  • cleanup() calls this.sessions.delete(sessionId) on both exits — line 1811 (the cached-directory early return) and line 1825 (the normal path).
  • All five this.sessions.set(...) sites (1023, 1064, 1095, 1132, 1178) are each followed by a scheduleCleanup(sessionId) call (1035, 1075, 1106, 1145, 1192), so every session created gets a cleanup timer.
  • Session IDs come from crypto.randomBytes(8).toString('hex'), which always satisfies the /^[0-9a-f]{16}$/ guard at line 1785, so that early return never strands an entry either.

What does leak

this.buildLogs. It is populated in _initLog (line 431) and deleted in exactly one place — line 1826, which sits after the isDirCached early return at 1808-1813. That branch deletes sessions and returns, so buildLogs and buildPromises are never cleared on it.

That branch is the cache-hit path, which is the one a long-running server takes most often when rebuilding repos it has seen before — precisely the scenario the issue describes. Each stranded entry holds up to 2000 log-line objects (bounded per entry by the shift() at line 442, but unbounded in the number of entries) plus a subscribers Set.

So the issue's diagnosis is stale, but its thesis is right: there is unbounded map growth in BuildExecutor cleanup that grows memory on long-running instances. It's buildLogs, not sessions.

Change

Releases both maps on the early-return branch, matching what the normal path already does:

if (isDirCached) {
  console.log(`[BuildCache] Keeping ${repoKey} directory (still in cache)`);
  this.sessions.delete(sessionId);
  this.buildLogs.delete(sessionId);
  this.buildPromises.delete(sessionId);
  return;
}

artifactCache.invalidateSession() deliberately stays on the normal path only — invalidating it here would defeat the cache this branch exists to preserve. The on-disk directory is likewise untouched.

Verification

  • npx tsc --noEmit in backend/ clean.
  • Every mutation site for buildLogs, buildPromises and pdfBuilds audited: pdfBuilds already self-cleans via promise.finally() at line 1778 and buildPromises partially self-cleans at 1496/1508, so buildLogs is the only map with no other release path.

Note: npm test is red on clean main independently of this branch.

@coderabbitai

coderabbitai Bot commented Jul 28, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@SakethSumanBathini, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 2 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5e6c7fec-6493-4556-9fc4-ba33bcb07f6f

📥 Commits

Reviewing files that changed from the base of the PR and between 2f06e6e and 0fc6aa7.

📒 Files selected for processing (1)
  • backend/src/services/buildExecutor.ts
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Unbounded Memory Growth in BuildExecutor.sessions In-Memory Map

1 participant