fix(cloud-task): drop unsafe append in log-gap inconsistency path

[sampennington]

Summary

Fixes a renderer OOM crash loop on long-running cloud tasks. Observed: 16 V8 OOM renderer crashes between 06:12 and 06:34 on 2026-05-08 against task aab06c8f-… (run accumulated 11k+ log entries).

reconcileCloudLogGapOnce had a fallback that appended update.newEntries on top of session.events whenever local + S3 fetches couldn't catch up to expectedCount. But newEntries is the snapshot's tail slice (positions [expectedCount-N, expectedCount]) — it's not contiguous with the renderer's processedLineCount. So each invocation:

• pushed unaligned events onto session.events (duplicates and gaps)
• bumped processedLineCount = latestCount + newEntries.length past entries we never actually had

With cloud-task watchers reconnecting every ~2 min on error: 'terminated', this stacked indefinitely until V8 OOM'd the renderer.

The fix: when the fetched logs lag behind expectedCount, log the existing Cloud task log count inconsistency warning and return. The next snapshot or logs update retries once the source has caught up. The success branch (S3/local catches up to expectedCount) is unchanged.

Test plan

• pnpm --filter code typecheck
• pnpm exec vitest run src/renderer/features/sessions/service/service.test.ts — all 80 tests pass
• Updated processes a pending cloud log gap… test to assert the corrected behavior: queue still drains (verified via second readLocalLogs call) but no append happens when fetches stay stale
• Manually exercise a long-running cloud task with intermittent stream terminated errors and confirm the renderer no longer OOMs

Notes

Two other related leaks remain (out of scope here, deferred):

1. emittedLogEntries in apps/code/src/main/services/cloud-task/service.ts grows unbounded on single-subscriber runs (only pruned in emitCurrentSnapshot, which only fires for 2nd+ subscribers).
2. emitCurrentSnapshot ships the full historical log (newEntries: snapshotEntries) to every newly-attached renderer subscriber — for an 11k-entry run that's a multi-MB IPC payload per re-attach.

Both are worth a follow-up. This PR is the conservative hotfix.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/code/src/renderer/features/sessions/service/service.ts:3568-3573
Now that the warning fires specifically when the fetch lagged behind `expectedCount`, adding `fetchedCount: rawEntries.length` would make it immediately clear how far behind the S3/local fetch was — useful for diagnosing future incidents without needing to correlate separate log lines.

```suggestion
    log.warn("Cloud task log count inconsistency", {
      taskRunId,
      currentCount,
      expectedCount,
      fetchedCount: rawEntries.length,
      entriesReceived: newEntries.length,
    });
```

_{Reviews (1): Last reviewed commit: "fix(cloud-task): drop unsafe append in l..." | Re-trigger Greptile}

[greptile-apps]

Now that the warning fires specifically when the fetch lagged behind expectedCount, adding fetchedCount: rawEntries.length would make it immediately clear how far behind the S3/local fetch was — useful for diagnosing future incidents without needing to correlate separate log lines.

Suggested change

	log.warn("Cloud task log count inconsistency", {
	taskRunId,
	currentCount,
	expectedCount,
	entriesReceived: newEntries.length,
	});
	log.warn("Cloud task log count inconsistency", {
	taskRunId,
	currentCount,
	expectedCount,
	fetchedCount: rawEntries.length,
	entriesReceived: newEntries.length,
	});

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/service/service.ts
Line: 3568-3573

Comment:
Now that the warning fires specifically when the fetch lagged behind `expectedCount`, adding `fetchedCount: rawEntries.length` would make it immediately clear how far behind the S3/local fetch was — useful for diagnosing future incidents without needing to correlate separate log lines.

```suggestion
    log.warn("Cloud task log count inconsistency", {
      taskRunId,
      currentCount,
      expectedCount,
      fetchedCount: rawEntries.length,
      entriesReceived: newEntries.length,
    });
```

How can I resolve this? If you propose a fix, please make it concise.

[sampennington]

Good call — added in 7e676a9.

[greptile-apps]

_{Reviews (2): Last reviewed commit: "log fetchedCount in cloud-log inconsiste..." | Re-trigger Greptile}

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Try greploops.

[tatoalo]

let's go