fix: retry PATCH requests and 403 rate limit errors

[Zopsss]

What does this PR do?

Google Calendar PATCH requests (e.g. updating hangout link/description after event creation) were silently failing on transient 403 rateLimitExceeded errors and never being retried. This caused a booking/calendar desync — the booking appeared successful in Cal.com but the calendar event was incomplete or missing the Meet link.

Two gaps in the default gaxios retry config caused this:

1. PATCH was not in httpMethodsToRetry (only GET, HEAD, PUT, OPTIONS, DELETE were retried by default)
2. HTTP 403 was not in statusCodesToRetry — but Google's API can return either 403 or 429 for rate limit errors per their error handling docs

Fix: explicitly pass a retryConfig when instantiating the calendar_v3.Calendar client in CalendarAuth.ts to override the gaxios defaults.

• Fixes [BUG] Google Calendar PATCH requests excluded from retry logic, causing silent booking/calendar desync #28834

Visual Demo (For contributors especially)

N/A — this is a silent failure fix with no visual change. The bug only surfaces under transient rate limit conditions on self-hosted instances with low-quota Google Cloud projects.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. N/A
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

Automated test: A unit test has been added in packages/app-store/googlecalendar/lib/__tests__/CalendarService.auth.test.ts that asserts the calendar_v3.Calendar client is instantiated with a retryConfig containing PATCH/POST in httpMethodsToRetry and [403, 403] in statusCodesToRetry.

Run it with:

npx vitest run packages/app-store/googlecalendar/lib/__tests__/CalendarService.auth.test.ts

[coderabbitai]

📝 Walkthrough

Walkthrough

The GoogleCalendar integration's CalendarAuth.getClient() method now includes explicit retry configuration when instantiating the Calendar client. The retry settings specify a maximum of 3 retries with 2 no-response retries, along with retriable HTTP methods (PATCH, POST) and status code ranges (1xx, 403, 429, 5xx). Corresponding test updates verify that the retryConfig option is properly passed to the Calendar constructor and that the configuration includes the expected HTTP methods and status codes for retry logic.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title clearly and concisely summarizes the main fix: adding retry logic for PATCH requests and HTTP 403 errors, which directly addresses the core issue in the linked problem.
Description check	✅ Passed	The PR description is comprehensive and clearly related to the changeset, explaining the problem, root causes, solution, and testing approach in detail.
Linked Issues check	✅ Passed	The PR fully addresses the primary objective from issue #28834: adding PATCH/POST to httpMethodsToRetry and HTTP 403 to statusCodesToRetry in the Calendar client's retryConfig.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to the linked issue: modifying CalendarAuth.ts to add retryConfig and adding corresponding unit tests in CalendarService.auth.test.ts.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

packages/app-store/googlecalendar/lib/__tests__/CalendarService.auth.test.ts (1)

217-224: Broaden retryConfig assertions to lock the full contract.

This currently verifies only PATCH/POST and 403. Consider asserting retry, noResponseRetries, and 429 too, so future retry-policy regressions don’t pass silently.

Suggested test tightening

       expect(calendarMock.calendar_v3.Calendar).toHaveBeenCalledWith(
         expect.objectContaining({
           retryConfig: expect.objectContaining({
+            retry: 3,
+            noResponseRetries: 2,
             httpMethodsToRetry: expect.arrayContaining(["PATCH", "POST"]),
-            statusCodesToRetry: expect.arrayContaining([[403, 403]]),
+            statusCodesToRetry: expect.arrayContaining([
+              [403, 403],
+              [429, 429],
+            ]),
           }),
         })
       );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/app-store/googlecalendar/lib/__tests__/CalendarService.auth.test.ts`
around lines 217 - 224, The test currently only asserts httpMethodsToRetry and
403 in the retryConfig; update the assertion against
calendarMock.calendar_v3.Calendar to lock the full retry contract by also
asserting the top-level retryConfig properties (e.g., retry: true),
noResponseRetries (expect the intended numeric value), and that
statusCodesToRetry includes both [403,403] and [429,429] in addition to the
existing checks for httpMethodsToRetry containing "PATCH" and "POST" so the test
fails if any of these retry-policy fields change unexpectedly.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In
`@packages/app-store/googlecalendar/lib/__tests__/CalendarService.auth.test.ts`:
- Around line 217-224: The test currently only asserts httpMethodsToRetry and
403 in the retryConfig; update the assertion against
calendarMock.calendar_v3.Calendar to lock the full retry contract by also
asserting the top-level retryConfig properties (e.g., retry: true),
noResponseRetries (expect the intended numeric value), and that
statusCodesToRetry includes both [403,403] and [429,429] in addition to the
existing checks for httpMethodsToRetry containing "PATCH" and "POST" so the test
fails if any of these retry-policy fields change unexpectedly.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ec9fb3f2-56e0-40c3-9907-80c89626b819

📥 Commits

Reviewing files that changed from the base of the PR and between 2911168 and 34c0dfb.

📒 Files selected for processing (2)

• packages/app-store/googlecalendar/lib/CalendarAuth.ts
• packages/app-store/googlecalendar/lib/__tests__/CalendarService.auth.test.ts