gog calendar update --with-meet should be idempotent (currently replaces existing Meet link)

[alexisperumal]

Summary

gog calendar update <calendarId> <eventId> --with-meet (added in v0.15.0, commit c453cbd, fixing #538) is not idempotent. Calling it on an event that already has a Meet link replaces the link with a fresh one. The prior link becomes invalid; anyone who saved it or had it cached loses access.

Reproduction

$ gog --version
v0.15.0 (e0338d5 2026-05-05T05:50:19Z)

# 1. Create an event without Meet
$ gog calendar create <calId> --summary "test" --from <iso> --to <iso>
  → event created, no hangoutLink

# 2. First --with-meet call (the originally-intended use case)
$ gog calendar update <calId> <eventId> --with-meet
  → hangoutLink: https://meet.google.com/kgz-tnmo-srt ✓

# 3. Second --with-meet call on the SAME event
$ gog calendar update <calId> <eventId> --with-meet
  → hangoutLink: https://meet.google.com/sov-gvar-bcz  ← different link!
  → prior link (kgz-tnmo-srt) now invalid

Why this matters

Two practical impact paths:

1. Cron / agent-driven workflows. AI agents (this is the use case from the original Feature request: add --with-meet to calendar update (parity with calendar create) #538) invoke gog from prompts that may retry under non-determinism, network blips, or deduplication-window edge cases. A second --with-meet invocation silently invalidates a Meet link an attendee may have already saved, joined, or shared.

2. Operator muscle memory. "Re-run the update" is a natural reflex when verifying a change. Today, that costs a Meet link.

The upstream commit message on c453cbd describes the feature as "adds Google Meet conferencing to an existing event" — the language implies additive, not destructive. Most users would expect "add Meet" to be a no-op when Meet is already present.

Suggested resolution

Idempotent by default; explicit --regenerate-meet for the rare replace case:

# Default behavior: idempotent. If event has Meet, return existing link unchanged.
gog calendar update <calId> <eventId> --with-meet

# Explicit regenerate (rare — coordinate with attendees first)
gog calendar update <calId> <eventId> --regenerate-meet

Implementation sketch (ahead of the actual code, since I haven't read the calendar PATCH path):

• On --with-meet, GET the event first.
• If event.conferenceData.entryPoints[].uri already exists, return success with the existing link (no PATCH).
• If absent, current path (conferenceData.createRequest + conferenceDataVersion=1).
• --regenerate-meet always sends the createRequest, replacing any existing.

Workaround we're using

Until upstream fixes, our agent-facing skill docs warn:

⚠️ Not idempotent. Before calling --with-meet, verify the event does NOT already have a Meet link. Inspect via gog calendar event <calId> <eventId> for hangoutLink / conferenceData. Only call --with-meet on Meet-less events.

Cron-triggered prompts include a "skip if hangoutLink present" guard.

Context

I'm @alexisperumal who filed the original #538. My agent fleet (3 instances on OpenClaw, all on v0.15.0 now) uses gog for both customer-facing (calendar invites with Meet) and internal operational flows. The non-idempotency surfaced during ad-hoc edge-case testing before promoting v0.15.0 to production servers — caught early, so no real-world incident, but the failure mode is plausible enough for a deliberate fleet-deploy gate.

Happy to test a fix once it lands. Thanks again for the responsiveness on #538 and #180.

[steipete]

Fixed on main in 8caea15. calendar update --with-meet is now idempotent when conference data already exists, including --scope future; explicit replacement is available via --regenerate-meet. Regression coverage added in internal/cmd/calendar_create_update_test.go.

[alexisperumal]

Thanks for the fast turnaround, @steipete — landed in <24h with exactly the API shape we proposed (idempotent default + opt-in --regenerate-meet). We'll pick it up on the next gog version we deploy across our agent fleet. Appreciate the regression coverage too.