Google Calendar & Microsoft Outlook Calendar - adding polling sources for upcoming events #18976
+322
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
Contributor
WalkthroughThe changes introduce polling-based alternatives to subscription-based sources for Google Calendar and Microsoft Outlook Calendar that periodically fetch upcoming events and emit them shortly before their scheduled start times. Version bumps in package.json files reflect these additions. Changes
Sequence DiagramssequenceDiagram
participant Poller as Polling Loop
participant Source as Polling Source
participant DB as Database
participant API as Calendar API
loop On Each Poll Cycle
Poller->>Source: Execute polling
Source->>DB: Get emitted events tracker
Source->>Source: Clean up past events
Source->>Source: Calculate time window (now → now + minutesBefore)
Source->>API: Fetch events in window
API-->>Source: Return events
loop For Each Event
Source->>Source: Check if already emitted
alt Event not emitted & within threshold
Source->>Source: Calculate timeRemaining
alt timeRemaining > 0 AND timeRemaining ≤ minutesBefore
Source->>DB: Record emitted event
Source->>Poller: Emit event with metadata
end
end
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
components/google_calendar/package.json(1 hunks)components/google_calendar/sources/upcoming-event-alert-polling/test-event.mjs(1 hunks)components/google_calendar/sources/upcoming-event-alert-polling/upcoming-event-alert-polling.mjs(1 hunks)components/microsoft_outlook_calendar/package.json(1 hunks)components/microsoft_outlook_calendar/sources/new-upcoming-event-polling/new-upcoming-event-polling.mjs(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2024-10-10T19:18:27.998Z
Learnt from: GTFalcao
Repo: PipedreamHQ/pipedream PR: 14265
File: components/the_magic_drip/sources/common.mjs:35-43
Timestamp: 2024-10-10T19:18:27.998Z
Learning: In `components/the_magic_drip/sources/common.mjs`, when processing items in `getAndProcessData`, `savedIds` is intentionally updated with IDs of both emitted and non-emitted items to avoid emitting retroactive events upon first deployment and ensure only new events are emitted as they occur.
Applied to files:
components/google_calendar/sources/upcoming-event-alert-polling/upcoming-event-alert-polling.mjs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: pnpm publish
- GitHub Check: Lint Code Base
- GitHub Check: Publish TypeScript components
- GitHub Check: Verify TypeScript components
Comment on lines
+1
to
+3
| import { DEFAULT_POLLING_SOURCE_TIMER_INTERVAL } from "@pipedream/platform"; | ||
| import microsoftOutlook from "../../microsoft_outlook_calendar.app.mjs"; | ||
| import sampleEmit from "./test-event.mjs"; |
Contributor
There was a problem hiding this comment.
Fix timezone handling before computing alert windows
Microsoft Graph returns event.start.dateTime in the calendar’s local time without an offset, paired with event.start.timeZone. Parsing it with new Date(event.start.dateTime) makes Node assume the runtime’s timezone (typically UTC), so the alert window is shifted by the user’s timezone offset. For example, a 9 AM Pacific event is treated as 9 AM UTC, causing the alert to fire ~7 hours early. Please normalize with the provided timezone before comparing against now.
@@
-import sampleEmit from "./test-event.mjs";
+import sampleEmit from "./test-event.mjs";
+import { DateTime } from "luxon";
@@
- const startTime = event.start
- ? new Date(event.start.dateTime)
- : null;
-
- if (!startTime) {
+ const start = event.start?.dateTime ?? event.start?.date;
+ if (!start) {
+ continue;
+ }
+ const zone = event.start?.timeZone
+ || event.originalStartTimeZone
+ || "UTC";
+ const startDateTime = DateTime.fromISO(start, { zone });
+ if (!startDateTime.isValid) {
+ continue;
+ }
+ const startTime = startDateTime.toJSDate();
+
+ if (!startTime) {
continue;
}
@@
- emittedEvents[event.id] = startTime.getTime();
+ emittedEvents[event.id] = startTime.getTime();Also applies to: 108-129
🤖 Prompt for AI Agents
In
components/microsoft_outlook_calendar/sources/new-upcoming-event-polling/new-upcoming-event-polling.mjs
around lines 1-3 and also apply same change to lines 108-129: the code currently
parses event.start.dateTime with new Date(...) which treats the timestamp as
runtime-local/UTC and ignores event.start.timeZone, shifting alert windows; fix
by parsing the ISO local date with the provided timeZone (e.g., use a
timezone-aware parser such as Luxon or moment-timezone) — create a DateTime by
combining event.start.dateTime and event.start.timeZone, convert that to a
consistent zone (preferably UTC) for comparisons with now, do the same for
event.end.dateTime, and use those normalized UTC timestamps when computing alert
windows and comparisons.
lcaresia
approved these changes
Nov 7, 2025
Collaborator
lcaresia
left a comment
lcaresia
left a comment
There was a problem hiding this comment.
Approved, but have some failed actions to look.
Collaborator
For Integration QA: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #18964
Summary by CodeRabbit
New Features
Releases