fix(outlook): make retried event creates duplicate-safe via transactionId

The retry config opts POSTs in via retryIdempotentOnly:false, but the executor's
isRetryableFailure covers 429 AND 500-599 — not just the throttle the comment
justified. A 5xx returned after Graph had already committed a create would be
retried and produce a duplicate calendar event.

create_event now sends a transactionId, which Graph documents for exactly this:
it discards a repeat POST carrying an id it has already seen. The request body is
built once per execution (formatRequestParams runs before the attempt loop), so
the id is stable across retries of a call and unique between calls.

The retry comment now describes what actually retries and why each non-idempotent
method is safe: PATCH replays the same partial body as a no-op, and respond is
state-idempotent though a post-commit retry can send the organizer a second
notification — accepted deliberately, since Graph exposes no transactionId for
accept/decline and failing outright under throttling is worse.

Author: waleedlatif1

apps/sim/tools/outlook/calendar-tools.test.ts

@@ -303,6 +303,25 @@ describe('outlook calendar tools', () => {
     expect(withComment).toEqual({ sendResponse: true, comment: 'See you there' })
   })
 
+  it('sends a stable transactionId so a retried create cannot duplicate the event', () => {
+    const body = outlookCalendarCreateEventTool.request.body as (
+      p: unknown
+    ) => Record<string, unknown>
+    const params = {
+      accessToken: 't',
+      subject: 'Sync',
+      startDateTime: '2025-06-03T10:00:00Z',
+      endDateTime: '2025-06-03T11:00:00Z',
+    }
+    const first = body(params)
+    expect(typeof first.transactionId).toBe('string')
+    expect(first.transactionId).toBeTruthy()
+
+    // Distinct executions must not share an id, or Graph would discard a genuine
+    // second event as a duplicate. (Retries reuse one body, built once per execution.)
+    expect(body(params).transactionId).not.toBe(first.transactionId)
+  })
+
   it('enables retry with backoff on every calendar tool (429/mailbox concurrency)', () => {
     for (const tool of tools) {
       expect(tool.request.retry?.enabled).toBe(true)

apps/sim/tools/outlook/calendar-utils.ts

@@ -12,10 +12,20 @@ import type { ToolRetryConfig } from '@/tools/types'
  *
  * Microsoft Graph throttles a single mailbox at roughly four concurrent requests and
  * returns 429 with a `Retry-After` header when calendar operations fan out (e.g. many
- * parallel event creates in a workflow). The tool executor retries 429/5xx with backoff
- * and honors `Retry-After`. `retryIdempotentOnly` is `false` so create/update/respond
- * (POST/PATCH) also retry — a 429 is a pre-processing throttle, so retrying does not
- * duplicate the event.
+ * parallel event creates in a workflow). `retryIdempotentOnly` is `false` so
+ * create/update/respond (POST/PATCH) retry too, rather than failing the whole workflow
+ * on a throttle.
+ *
+ * The executor retries **429 and 5xx** (`isRetryableFailure`), not 429 alone, so each
+ * non-idempotent method has to be safe against a retry that follows an already-committed
+ * write:
+ * - `create_event` (POST) sends a per-execution `transactionId`; Graph uses it to discard
+ *   the duplicate POST, so a 5xx-after-commit cannot create a second event.
+ * - `update_event` (PATCH) resends the same partial body, so replaying it is a no-op.
+ * - `respond` (POST accept/decline) is state-idempotent — the resulting `responseStatus`
+ *   is identical — but a retry after a committed write can send the organizer a second
+ *   notification email. Accepted: a duplicate notification is less harmful than failing
+ *   the response outright under throttling, and Graph exposes no transactionId for it.
  */
 export const CALENDAR_RETRY: ToolRetryConfig = {
   enabled: true,

apps/sim/tools/outlook/calendar_create_event.ts

@@ -1,3 +1,4 @@
+import { generateId } from '@sim/utils/id'
 import { ErrorExtractorId } from '@/tools/error-extractors'
 import {
   buildAllDayRange,
@@ -135,7 +136,16 @@ export const outlookCalendarCreateEventTool: ToolConfig<
       // date-only input for all-day events.
       const bothBoundsDateOnly = isDateOnly(params.startDateTime) && isDateOnly(params.endDateTime)
       const isAllDay = toBool(params.isAllDay) || bothBoundsDateOnly
-      const event: Record<string, unknown> = { subject: params.subject }
+      const event: Record<string, unknown> = {
+        subject: params.subject,
+        // Graph de-duplicates create-event POSTs that repeat a transactionId, which is
+        // exactly the retry case: the executor retries 5xx as well as 429, so a failure
+        // returned after Graph already committed the event would otherwise create a
+        // duplicate. The request body is built once per execution and reused across
+        // attempts, so this id is stable for all retries of this call and unique across
+        // calls. https://learn.microsoft.com/en-us/graph/api/resources/event
+        transactionId: generateId(),
+      }
 
       if (isAllDay) {
         // All-day events need midnight bounds with an exclusive end day.