fix(code): bound cloud session reconnect attempts with cumulative cap

[k11kirky]

Problem

When a cloud run stream repeatedly closes with a clean EOF (no error), the per-attempt reconnect counter was being reset to zero on each clean disconnect. This allowed the watcher to loop indefinitely without ever hitting the MAX_SSE_RECONNECT_ATTEMPTS limit, leaving users stuck watching a run that can never be reached.

Changes

A new cumulativeReconnectAttempts counter was added to the watcher state that increments on every reconnect attempt regardless of whether the disconnect was clean or errored. Unlike reconnectAttempts, it is never reset by a clean EOF — only by a successful SSE event or confirmed in-progress poll response. If the cumulative count exceeds MAX_CUMULATIVE_RECONNECT_ATTEMPTS (30), the watcher is failed with a retryable "Cloud run unreachable" error.

The previous behavior of resetting reconnectAttempts to zero on clean EOF was removed, since the cumulative counter now handles the runaway loop case independently.

How did you test this?

A new automated test was added that mocks the stream to always return a clean empty SSE response and verifies that after exhausting the cumulative reconnect budget, the watcher emits an error update with kind: "error" and the expected "Cloud run unreachable" message.

Publish to changelog?

No

[k11kirky]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(code): bound cloud session reconnect attempts with cumulative cap #2285 👈 (View in Graphite)
• fix(code): break unrecoverable cloud log reconcile loop on stable deficiency #2284
• fix(code): coalesce writeLocalLogs per taskRunId to stop main-thread storm #2255
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[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/main/services/cloud-task/service.ts:1077-1079
When the poll confirms the run is making progress (`stateChanged=true`), only `cumulativeReconnectAttempts` is reset while `reconnectAttempts` retains its prior error count. A watcher that has accumulated 5 error reconnects, then sees a poll-confirmed state change, then gets just 1 more error will immediately fail with "Cloud stream disconnected" — even though the run was confirmed alive. Reset `reconnectAttempts` here too so both budgets are aligned when real progress is observed.

```suggestion
      if (stateChanged) {
        // Polled progress proves the run is alive — don't burn cumulative budget.
        watcher.cumulativeReconnectAttempts = 0;
        watcher.reconnectAttempts = 0;
```

_{Reviews (1): Last reviewed commit: "chore(code): trim verbose comments on cl..." | Re-trigger Greptile}

[greptile-apps]

When the poll confirms the run is making progress (stateChanged=true), only cumulativeReconnectAttempts is reset while reconnectAttempts retains its prior error count. A watcher that has accumulated 5 error reconnects, then sees a poll-confirmed state change, then gets just 1 more error will immediately fail with "Cloud stream disconnected" — even though the run was confirmed alive. Reset reconnectAttempts here too so both budgets are aligned when real progress is observed.

Suggested change

	if (stateChanged) {
	// Polled progress proves the run is alive — don't burn cumulative budget.
	watcher.cumulativeReconnectAttempts = 0;
	if (stateChanged) {
	// Polled progress proves the run is alive — don't burn cumulative budget.
	watcher.cumulativeReconnectAttempts = 0;
	watcher.reconnectAttempts = 0;

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/main/services/cloud-task/service.ts
Line: 1077-1079

Comment:
When the poll confirms the run is making progress (`stateChanged=true`), only `cumulativeReconnectAttempts` is reset while `reconnectAttempts` retains its prior error count. A watcher that has accumulated 5 error reconnects, then sees a poll-confirmed state change, then gets just 1 more error will immediately fail with "Cloud stream disconnected" — even though the run was confirmed alive. Reset `reconnectAttempts` here too so both budgets are aligned when real progress is observed.

```suggestion
      if (stateChanged) {
        // Polled progress proves the run is alive — don't burn cumulative budget.
        watcher.cumulativeReconnectAttempts = 0;
        watcher.reconnectAttempts = 0;
```

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

[jonathanlab]

Greptile comment seems valid here. Wondering if we should make this some kind of exponential backoff instead?