Booking reminder sent after Google Calendar cancellation #5

Summary

A test booking received a Calnode reminder after Google Calendar had sent a cancellation for the same booking. The booking ID in the cancellation exactly matches the booking reference in the later reminder. This records an observed October 7 incident; no new live reproduction has been run.

Observed timeline

All times are UTC+07:00.

• October 6, 2026, 11:26:37: confirmation sent for a 30-minute meeting on October 7, 09:30–10:00.
• October 6, 15:03:02: Google Calendar sent a cancellation notice for the booking.
• October 7, 07:30:04: Calnode sent the attendee an upcoming-booking reminder with the original meeting details and add-to-calendar links.

The reminder arrived about 16 hours 27 minutes after the cancellation. All three messages reference the same booking. Attendee identities, addresses, booking IDs, meeting URLs, and mailbox links are omitted.

Current technical evidence

Checked October 8, 2026:

• GitHub's Railway deployment record identifies fc1fb54 as the active production deployment, completed October 6 at approximately 08:58 UTC.
• internal/worker/worker.go already skips reminder delivery when the local booking status is not confirmed.
• TestWorker_skipsReminderForCancelledBooking covers a booking seeded as canceled locally. It does not establish that a Google-origin cancellation is synchronized back into Calnode.
• internal/handler/calendar_reconcile.go currently reconciles Calnode booking state outward to calendars: cancellation, missing-event creation, and rescheduling. It does not provide a Google-origin cancellation detection pass.
• PRs fix: allow event URL changes after bookings #1 and fix: explain event type deletion blocked by booking history #2 cover event URL changes and event-type deletion errors. PRs chore: integrate upstream main into CoderPush deployment branch #3 and chore: align fork main with CoderPush deployment code #4 remain unmerged and cover upstream invite/RSVP integration; they do not establish that this incident was fixed and deployed.

The exact action used to cancel the original event and Calnode's stored status at reminder send time have not been inspected. Do not infer a specific root cause from the emails alone. A read-only check of four clean local worktrees found no follow-up reminder/cancellation fix. The reminder worker and reminder tests are unchanged across the inspected local branches, the production revision, and integration revision 6ff511b. The existing local-cancellation regression dates to June 14 (dfda3d3). Integration RSVP handling updates attendee RSVP state, not booking cancellation. Runtime/database access was unavailable; no new tests or live booking/email actions were run.

Reproduction to verify

1. Create a test booking with Google Calendar connected and a reminder scheduled before its start.
2. Cancel the associated event in Google Calendar before the reminder is due; verify the cancellation notification.
3. Allow the original reminder time to pass.
4. Check whether Calnode still sends the upcoming-booking reminder and inspect the local booking status.

These are proposed reproduction steps, not a newly executed end-to-end test.

Expected

The canceled meeting should not generate an upcoming-booking reminder. Reconcile external cancellation into the booking/reminder state, or explicitly define and surface the supported cancellation path if Google-origin cancellation is intentionally unsupported.

Actual

The October 7 reminder described the previously canceled meeting as upcoming.

Acceptance checks

• Confirm the original cancellation path and local booking status at reminder time.
• Cover Google-origin cancellation before reminder time with a regression test.
• Preserve existing suppression for bookings canceled in Calnode.
• Ensure queued/retried reminders honor the final canceled state.
• Preserve expected reminders for active bookings.
• Verify the applicable fix is deployed before closing the issue.

Resolution — October 8, 2026

Shipped in PR #6, merged to main as c41e21c03062ff64c58be53ca1f177672ec8e983. Railway production deployment daf623aa-9885-4a8e-8b8d-80585c66408a completed successfully. The live /version and /readyz endpoints report that exact commit, the admin page and authenticated bookings API return HTTP 200, and startup logs confirm Google Calendar and CalDAV are configured. No schema migration was added.

The worker checks the primary host's recorded Google event before sending. Explicit external cancellation suppresses the reminder; lookup errors use the existing retry/failure policy. Local cancellation is checked again after the lookup. Google settings reloads preserve other calendar providers and their reminders.

Regression tests cover locally confirmed bookings whose Google event is cancelled, active events, lookup errors/recovery, local cancellation during lookup, and Microsoft/CalDAV reminders after Google credential save/clear. Full Go tests, vet and backend builds pass on both fork and upstream. The upstream counterpart remains PR Calnode#133.

Verification limit: no new live cancellation-to-reminder email experiment was performed. The exact historical cancellation action and booking state at the October 7 send time remain unverified; the first historical acceptance item is intentionally left unchecked. Closing the reminder-delivery defect based on the regression coverage and verified production release, not claiming historical reconstruction or full inbound calendar synchronization. External cancellation still does not change local booking status, release availability or trigger refunds.