RomitGitHubDevin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* fix: add missing vi.mock() calls to prevent vitest worker shutdown flakiness
Add vi.mock() calls for modules that trigger background network requests
or database connections during import. These transitive imports can cause
the vitest worker RPC to shut down while pending fetch/network operations
are still in flight, resulting in flaky test failures with:
Error: [vitest-worker]: Closing rpc while "fetch" was pending
The primary modules mocked are:
- @calcom/app-store/delegationCredential (triggers credential lookups)
- @calcom/prisma (triggers database initialization)
- @calcom/features/calendars/lib/CalendarManager (triggers calendar API calls)
- @calcom/features/auth/lib/verifyEmail (triggers email service)
- @calcom/lib/domainManager/organization (triggers domain lookups)
Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* fix: remove conflicting empty prisma mocks from files with prismock/prismaMock setups
- Remove vi.mock('@calcom/prisma', () => ({ default: {}, prisma: {} })) from 28 files
that already have prismock/prismaMock test doubles. Vitest hoists all vi.mock() calls
and the last one wins, so these empty mocks were overriding the functional test doubles.
- Fix CalendarSubscriptionService.test.ts to reuse the shared mock from
__mocks__/delegationCredential instead of creating a new unconfigured vi.fn()
- Remove DelegationCredentialRepository.test.ts empty prisma mock (different pattern)
- Remove vi.mock from inside beforeEach in intentToCreateOrg.handler.test.ts
Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* fix: add comprehensive delegationCredential mock exports to prevent CI test failures
The vi.mock blocks for @calcom/app-store/delegationCredential were missing
exports that the code under test transitively imports (e.g.
enrichUsersWithDelegationCredentials, enrichUserWithDelegationCredentialsIncludeServiceAccountKey,
buildAllCredentials, getFirstDelegationConferencingCredentialAppLocation).
Added all exports with passthrough implementations so the booking flow
works correctly without triggering real network requests.
Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* fix: correct credential mock return shapes to match real module API
Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* fix: revert unintended yarn.lock changes
Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
---------
Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
2026-03-17 09:55:37 +05:30
Benny JooGitHubbenny@cal.com <sldisek783@gmail.com>Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* fix: prevent 500 error when deleting calendar events with empty uid
This fix addresses a 500 error that occurs when trying to delete a Google
Calendar event with an empty event ID, which results in a malformed API URL.
Root cause: When calendar event creation fails or returns without an ID,
booking references were being created with empty uids. Later, when trying
to delete these events (e.g., during reschedule), the empty uid caused
a 404 from Google Calendar API which was then thrown as a 500 error.
Changes:
1. CalendarManager.deleteEvent: Added validation to skip deletion if
bookingRefUid is empty, with appropriate error logging. This is a
safety net for existing bad data in the database.
2. EventManager.create: Added filtering to exclude booking references
with empty uids from being stored, with error logging to help
diagnose the root cause of missing event IDs.
3. EventManager.updateLocation: Same filtering applied for consistency.
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* fix: revert EventManager filtering to preserve existing behavior
The test expects that booking references with empty uids are still created
when calendar event creation fails. This is intentional behavior to track
failed calendar syncs. The CalendarManager.deleteEvent fix handles the
deletion case gracefully by skipping the API call when uid is empty.
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* fix: throw ErrorWithCode instead of silently returning when bookingRefUid is empty
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* fix: validate uid before calling calendar.deleteEvent to prevent 500 error
- Add uid check in lastAttendeeDeleteBooking.ts before calling calendar.deleteEvent
- Add uid check in EventManager.updateAllCalendarEvents before calling calendar.deleteEvent
- Revert CalendarManager.deleteEvent changes (validation at call sites is the proper fix)
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* fix: add error logging safeguard in CalendarManager.deleteEvent for empty bookingRefUid
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* fix: move bookingRefUid check before getCalendar call
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* fix: prevent storing booking references with empty uid when calendar event creation fails
Root cause fix: Change the check from 'if (createdEvent)' to 'if (createdEvent.createdEvent)'
in createAllCalendarEvents to prevent failed calendar events from being added to results.
This prevents empty uids from being stored in the database in the first place, which
was causing 500 errors when trying to delete non-existent calendar events later.
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* test: update test to expect no calendar reference when calendar event creation fails
The root cause fix changes behavior so that failed calendar events no longer
create booking references with empty uids. This test now expects an empty
references array when calendar event creation fails, which is the correct
behavior that prevents 500 errors later when trying to delete non-existent
calendar events.
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* refactor: use createdEvent.success instead of createdEvent.createdEvent
Using success is more semantically clear since it explicitly checks the
success status rather than checking if the nested object exists.
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* refactor: use optional chaining for createdEvent?.success
Using optional chaining is safer in case createdEvent is somehow undefined.
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* revert: remove root cause fix to preserve backfilling script compatibility
The root cause fix (checking createdEvent?.success instead of createdEvent)
would break the backfilling script that relies on booking references with
empty uids to identify which bookings need backfilling.
This PR now only includes defensive checks to prevent 500 errors when
deleting calendar events with empty uids.
Co-Authored-By: benny@cal.com <sldisek783@gmail.com>
* revert
* fix
---------
Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* fix: event not created
* Update CalendarManager.ts
* Add tests: packages/features/calendars/lib/CalendarManager.ts
Generated by Paragon from proposal for PR #27675
* Add tests: packages/features/calendars/lib/CalendarManager.test.ts
Generated by Paragon from proposal for PR #27675
* Export processEvent for testing and refactor logic
* Fix missing newline at end of CalendarManager.test.ts
Add missing newline at the end of the file.
* fix test