fix: Return error message from getConnectedCalendar

[joeauyeung]

What does this PR do?

• Returns the error message from a calendar if calling getConnectedCalendar

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. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

[cubic-dev-ai]

No issues found across 1 file

[github-actions]

E2E results are ready!

• Workflow #89880.1 latest results

[Udit-takkar]

are we okay exposing this to the end user?

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
cal	Ignored			Nov 24, 2025 7:17pm
cal-eu	Ignored			Nov 24, 2025 7:17pm

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (all 1 issues)

Understand the root cause of the following 1 issues and fix them.


<file name="packages/features/calendars/lib/CalendarManager.ts">

<violation number="1" location="packages/features/calendars/lib/CalendarManager.ts:124">
`errorMessage` is now initialized with the raw `error` object, but it is only converted to a string inside the `invalid_grant` and `CalendarAppDelegationCredentialError` branches. For every other error, `errorMessage` remains an `Error` instance, so the returned `{ error: { message: errorMessage } }` serializes to `{}` because `Error` properties are non-enumerable. Clients therefore lose the actual failure reason, which is the opposite of the PR goal of returning the calendar error message.</violation>
</file>

_{Reply to cubic to teach it or ask questions. Re-run a review with @cubic-dev-ai review this PR}

[cubic-dev-ai]

errorMessage is now initialized with the raw error object, but it is only converted to a string inside the invalid_grant and CalendarAppDelegationCredentialError branches. For every other error, errorMessage remains an Error instance, so the returned { error: { message: errorMessage } } serializes to {} because Error properties are non-enumerable. Clients therefore lose the actual failure reason, which is the opposite of the PR goal of returning the calendar error message.

Prompt for AI agents

Address the following comment on packages/features/calendars/lib/CalendarManager.ts at line 124:

<comment>`errorMessage` is now initialized with the raw `error` object, but it is only converted to a string inside the `invalid_grant` and `CalendarAppDelegationCredentialError` branches. For every other error, `errorMessage` remains an `Error` instance, so the returned `{ error: { message: errorMessage } }` serializes to `{}` because `Error` properties are non-enumerable. Clients therefore lose the actual failure reason, which is the opposite of the PR goal of returning the calendar error message.</comment>

<file context>
@@ -122,7 +121,7 @@ export const getConnectedCalendars = async (
         };
       } catch (error) {
-        let errorMessage = &quot;Could not get connected calendars&quot;;
+        let errorMessage = error;
 
         // Here you can expect for specific errors
</file context>

Suggested change

	let errorMessage = error;
	let errorMessage = error instanceof Error ? error.message : typeof error === "string" ? error : "Could not get connected calendars";