Move an event to another calendar with hey event edit --calendar - #513
Merged
Merged
Conversation
--calendar on a whole-event edit meant two things: the calendar to file the event on, and the only calendar to look for it on. A move looked for the event on its destination, where it is not yet, so it always answered not found (#512). The event is now looked for over every calendar, as an --occurrence edit already does, and --calendar is only where it goes. A move HEY will not make now says so. HEY files only on a calendar you own or share and answers 404 for any other, which reached the reader as a bare "Form request failed (HTTP 404)"; that is now named as the calendar. And an event you cannot edit, such as an invitation, moves only onto a calendar nobody else is on: HEY otherwise drops the calendar from the update and answers with the event where it was, which the edit reported as updated. The calendar HEY answers with is now checked against the one asked for.
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Move verification can still report unconfirmed success, and update-time 404s are attributed ambiguously.
Review effort: Balanced
Findings: 2
Open (2)
What changed in this PR
Fixes event moves by separating event discovery from the destination calendar.
Changes:
- Searches all calendars before editing.
- Detects rejected or silently ignored moves.
- Updates tests, CLI help, documentation, and agent guidance.
[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or rungh pr ready --undo.
Click "Ready for review" or rungh pr readyto reengage.
| File | Description |
|---|---|
internal/cmd/events.go |
Implements move lookup, validation, and errors. |
internal/cmd/events_test.go |
Tests successful and rejected moves. |
internal/cmd/events_zone_test.go |
Updates zone tests for new calendar semantics. |
docs/cli.md |
Documents event moves. |
skills/hey/SKILL.md |
Updates agent-facing guidance. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
An older HEY redirects after an update, and the SDK then hands back only the event's id, so a move went unconfirmed and was reported as updated. The event is now read again on the day it starts to see which calendar it is on. A 404 on a move can be the calendar or an event deleted since it was read, and nothing in the answer says which, so the refusal names both instead of blaming the calendar.
When HEY answers a move with the event's id alone, the event was read back on the requested start date as one UTC day. An event keeps its own zone's date, so a morning in Tokyo or an evening in Los Angeles sat on the neighbouring UTC day and was missed, as was an event whose date change HEY kept from happening. The read-back now spans the day it started on and the day it was asked to start on, a day wide either side. A read-back that failed after the write went through was always reported as an API error. It keeps its own code now, so an expired sign-in or a rate limit still exits as one. The event is looked for calendar by calendar and the search stops at the one it is on. Reading every calendar meant one that could not be read, listed after the event's, stood in the way of the edit. A refused move says what HEY still saved: an invitee's circle, countdown and reminders go through without the calendar. The help and docs say an event on a subscription does not move at all.
robzolkos
requested
a balanced review from Copilot
and removed request for
a team
September 28, 2026 10:09
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
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.
Fixes #512.
hey event edit <id> --calendar <id>could never move an event.--calendarwas both the calendar to file the event on and the only calendar the edit looked for it on, so a move looked on the destination, where the event is not yet, and answerednot_found.A whole-event edit now looks for the event over every calendar, as an
--occurrenceedit already does, and--calendaris only where the event goes. Passing the day it starts still keeps the read to one day.Two ways a move could still go wrong silently now say what happened:
Form request failed (HTTP 404)with codeapi. It is nownot_found: "HEY cannot move event N to calendar M", with a hint pointing athey calendar list.forbiddenwhen they differ.HEY began accepting that invitee move recently (the web app's calendar menu had the same silent failure). Until that reaches every server, an invitation that can't move gets the
forbiddenanswer rather than a false "Event updated".--help,docs/cli.mdand the skill no longer say--calendarlimits the search. They describe it as the destination and say which calendars can take an event. The zone tests dropped the--calendar 9they passed only to narrow the search, since it would now mean "move to 9".Summary by cubic
Fixes #512 so
hey event edit --calendaractually moves the event, instead of never finding it because the edit only searched the destination calendar.Bug Fixes
--calendarnames only where the event moves to, and passing the start day still limits the search to that day.not_foundnaming both and suggestinghey calendar list.forbiddeninstead of falsely reporting "Event updated", and a read-back failure keeps its own error code.--help,docs/cli.md, and the skill now describe--calendaras the destination and the calendars that can take an event; tests no longer pass--calendarjust to narrow the search.Written for commit 55a0b2a. Summary will update on new commits.