Greptile Summary

This PR fixes a real and well-described production issue: the MS Teams typing indicator firing in a tight loop during long agent runs, hitting the Teams 429 rate limit and creating a cascading failure spiral. The approach — a 3-second minimum interval, a 30-second post-429 suppression window, and a typingStopped flag wired to markDispatchIdle() — is clean and correctly scoped to the per-turn closure.

Key changes:

• sendTypingIndicator now guards against over-firing with lastTypingSentAt (throttle) and typingSuppressedUntil (backoff).
• typingStopped = true in markDispatchIdle() prevents the indicator from continuing after the response is sent.
• A try/catch wraps withRevokedProxyFallback to detect 429 responses.

Issue found:

• The catch block silently swallows all non-429 errors. Previously, any error from sendTypingIndicator propagated to the pipeline's onStartError handler (which calls logTypingFailure). After this change, only 429s are acted on and all other errors are silently discarded, reducing observability. Re-throwing non-429 errors would restore the original error-logging behaviour for unexpected failures.

Confidence Score: 4/5

• Safe to merge after fixing the non-429 error handling in the catch block.
• The throttling logic and stop-flag are correct and well-structured. The only issue — silently swallowing non-429 errors and bypassing onStartError — is a one-line fix (re-throw non-429 errors). It doesn't affect the primary fix path (429 rate-limit suppression) but does reduce observability for other failure modes. Everything else looks solid.
• extensions/msteams/src/reply-dispatcher.ts — catch block at lines 90–96 needs to re-throw non-429 errors.

This is a comment left during a code review.
Path: extensions/msteams/src/reply-dispatcher.ts
Line: 90-96

Comment:
**Non-429 errors are silently swallowed**

The `try/catch` wraps the entire `withRevokedProxyFallback` call but only acts on 429-class errors. Any other error (network failure, invalid activity, SDK error, etc.) is now silently discarded here, whereas before the PR it would propagate out of `sendTypingIndicator` and be caught by the pipeline's `onStartError` handler (which logs via `logTypingFailure`). This loses observability for non-429 failures.

Re-throw anything that isn't a rate-limit error so the existing error-logging path stays intact:

```suggestion
    } catch (err: unknown) {
      const errStr = String(err);
      if (errStr.includes("429") || errStr.includes("quota exceeded")) {
        typingSuppressedUntil = Date.now() + TYPING_BACKOFF_MS;
        params.log.debug?.(`msteams typing suppressed for ${TYPING_BACKOFF_MS}ms after 429`);
      } else {
        throw err;
      }
    }
```

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

_{Reviews (1): Last reviewed commit: "fix(msteams): throttle typing indicator ..." | Re-trigger Greptile}

Addressed the review feedback in cf6192b: non-429 errors now re-throw so they reach onStartError / logTypingFailure as before. Only 429/quota-exceeded errors are caught and suppressed.

Closing this because the original symptom appears to have been superseded by the move to the official Teams SDK, so this PR no longer looks like the right path forward.

If the typing/rate-limit spiral still reproduces on the current Teams implementation, we can open a fresh PR against the updated code path with current logs.