Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
WalkthroughDeletes the target recurring instance first, then trims the original recurrence and creates a new recurring event inside a try/catch; on failure the action attempts to restore the deleted instance and emits partial-failure messaging. Action and package versions bumped. Changes
Sequence Diagram(s)sequenceDiagram
participant Action
participant GoogleCalendar
participant Logger
Action->>GoogleCalendar: DELETE instance (instanceId)
GoogleCalendar-->>Action: 200 OK
Action->>GoogleCalendar: TRY: PATCH original event (RRULE trimmed -> UNTIL)
GoogleCalendar-->>Action: 200 OK
Action->>GoogleCalendar: CREATE new event (newRecurrence / attendees / timezone)
GoogleCalendar-->>Action: 200 Created
Action->>Logger: emit success summary
alt PATCH/CREATE fails
Action->>GoogleCalendar: PATCH deleted instance -> status "confirmed" (restore)
GoogleCalendar-->>Action: 200 OK / Error
Action->>Logger: emit partial-failure summary (restored or restore failed)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
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. 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
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@components/google_calendar/actions/update-following-instances/update-following-instances.mjs`:
- Around line 194-203: The deleteEvent call (this.googleCalendar.deleteEvent) is
non-atomic with the subsequent updateEvent/createEvent steps so if updateEvent
or createEvent fails the original instance is permanently lost; wrap the Step
4/5 sequence (the calls to updateEvent and createEvent) in a try/catch and in
the catch attempt to re-create the deleted instance (using this.calendarId,
this.instanceId and the original event payload/state you saved before deletion)
as a fallback, and if re-creation also fails emit a clear, distinct
$.export("$summary", ...) message indicating a partial-failure state (deleted
original instance, replacement not created) so callers/users can take corrective
action.
components/google_calendar/actions/update-following-instances/update-following-instances.mjs
Show resolved
Hide resolved
jcortes
force-pushed
the
fix-issue-20056-google-calendar
branch
from
082c3ce to
473506b
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@components/google_calendar/actions/update-following-instances/update-following-instances.mjs`:
- Around line 232-243: When building newRecurrence in update-following-instances
(the block that assigns newRecurrence when this.repeatFrequency is falsy), do
not reuse originalEvent.recurrence verbatim if it contains a COUNT=... rule;
instead strip any COUNT component from the inherited RRULE string (use the same
COUNT-removal regex/logic already used in modifyRecurrenceRule) so the tail
series does not reapply the original total-count and over-generate
instances—i.e., detect COUNT in originalEvent.recurrence and return a recurrence
string with COUNT removed (or otherwise replaced with UNTIL if you choose option
2), but default to removing COUNT when no new repeatFrequency is provided.
- Around line 275-292: When attempting the split, set a boolean flag (e.g.,
step4TrimApplied) before calling this.googleCalendar.updateEvent(...) that
performs the Step 4 RRULE trim so you can detect that the original series was
modified; in the outer catch where you currently try to restore the instance
(catch (splitError)), export a partial-failure summary if the restore succeeds
and step4TrimApplied is true (e.g., $.export("$summary", "Partial failure: split
failed but original instance was restored; the series RRULE was already modified
and may require manual repair.")), and keep the existing summary only for the
nested catch (_restoreError) where restoration itself fails; ensure the flag is
set immediately prior to calling updateEvent and cleared/left as-is based on
outcome so the rethrown splitError always accompanies the proper summary.
components/google_calendar/actions/update-following-instances/update-following-instances.mjs
Show resolved
Hide resolved
components/google_calendar/actions/update-following-instances/update-following-instances.mjs
Show resolved
Hide resolved
jcortes
force-pushed
the
fix-issue-20056-google-calendar
branch
2 times, most recently
from
0967e15 to
c780922
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@components/google_calendar/actions/update-following-instances/update-following-instances.mjs`:
- Around line 287-295: The restore/updateEvent call is sending the original
sendUpdates value which can trigger duplicate attendee notifications; change the
restore path so the updateEvent call uses sendUpdates coerced to "none" (e.g.,
replace passing this.sendUpdates with a local/inline value forced to "none" for
the restore) when calling this.googleCalendar.updateEvent with calendarId:
this.calendarId, eventId: this.instanceId and requestBody: { ...targetInstance,
status: "confirmed" }; ensure other code paths still use the original
this.sendUpdates.
- Around line 253-272: The createEvent call is passing the event payload under
resource which the underlying events.insert expects as requestBody, so replace
the resource property with requestBody in the createEvent invocation inside
update-following-instances (the call that constructs newEvent) and do the same
in create-event (the createEvent wrapper usage around line 147) so the payload
is sent correctly; locate the calls to this.googleCalendar.createEvent and
change the argument object to use requestBody: { summary..., start..., end...,
recurrence..., attendees..., colorId... } instead of resource.
components/google_calendar/actions/update-following-instances/update-following-instances.mjs
Show resolved
Hide resolved
components/google_calendar/actions/update-following-instances/update-following-instances.mjs
Show resolved
Hide resolved
… instance when rescheduling a recurring event
jcortes
force-pushed
the
fix-issue-20056-google-calendar
branch
from
c780922 to
4cc7515
Compare
Contributor
There was a problem hiding this comment.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In
`@components/google_calendar/actions/update-following-instances/update-following-instances.mjs`:
- Around line 287-295: The restore path currently calls
this.googleCalendar.updateEvent with sendUpdates: this.sendUpdates which can
re-notify attendees; change the updateEvent call in the restore/error-recovery
branch so it uses sendUpdates: "none" (replace the this.sendUpdates usage) to
prevent a second invite; update the call around this.googleCalendar.updateEvent
(the block that sends targetInstance/status: "confirmed" for this.instanceId) to
hard-code "none" for sendUpdates.
- Around line 253-272: The event payload is being passed under the
non‑recognized "resource" key (e.g., in update-following-instances's createEvent
call and create-event action) so events.insert() drops the body; either change
the createEvent call sites to pass the payload under "requestBody" (replace the
resource: {...} object with requestBody: {...}) or update the createEvent
wrapper in google_calendar.app.mjs to translate incoming resource -> requestBody
before calling events.insert(); verify by checking the createEvent wrapper and
requestHandler for any mapping and ensure events.insert() receives a requestBody
containing summary, start, end, recurrence, attendees, colorId, etc.
michelle0927
approved these changes
Feb 18, 2026
Collaborator
michelle0927
left a comment
michelle0927
left a comment
There was a problem hiding this comment.
LGTM! Passed all QA tests! Ready for Release!
Collaborator
|
✅ All tests passed - ready for release!
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
WHY
Resolves #20056
Summary by CodeRabbit
Bug Fixes
Chores