google-calendar: stable timestamps on cancellation and description notes by KrisBraun · Pull Request #145 · plotday/plot

KrisBraun · 2026-05-20T01:51:08Z

Summary

Two related bugs surfaced when a recurring Google Calendar event was edited via "this and future occurrences":

A previously-cancelled occurrence's note ("… cancelled the March 18 occurrence.") got re-stamped to "now" and bumped the thread to the top of activity. Root cause: the note's created came from event.updated, which Google bumps when the series is touched. Google doesn't actually tell us when (or by whom) an occurrence was cancelled.
A description edit silently overwrote the existing description note instead of recording the change as history.

Changes

Cancellation notes — stamp created with the time the connector first noticed the cancellation (persisted in connector storage via this.set/get) and reuse that timestamp on every subsequent sync. Applied to both occurrence-level (prepareEventInstance) and master-level cancellation paths. Dropped the "{organizer} cancelled …" attribution since event.organizer is the organizer, not the canceller.

Description notes — key is now description-${sha256-8(content)} instead of "description". Identical content is an idempotent upsert; edited content produces a new note while prior versions remain on the thread as history. created is stamped from the first time the connector observed each hash so unrelated re-syncs don't drag the note forward in the activity feed.

Added two small helpers:

hashContent(content) in google-api.ts — SHA-256, first 8 bytes hex.
Connector.firstSeenAt(key) — get-or-stamp pattern over this.set/this.get.

Test plan

On a recurring event with a cancelled occurrence, edit "this and future occurrences" — the existing cancellation note keeps its original timestamp and the thread does not bump.
Cancel a fresh occurrence — a new note appears once, dated at notice time, and does not re-bump on subsequent syncs.
Edit an event description — a new description note appears alongside the prior one (history preserved); re-syncing without further edits is a no-op.
Identical descriptions across users on the same meeting still converge on one shared note (same hash → same key on the shared iCalUID thread).

🤖 Generated with Claude Code

Two related bugs surfaced when a recurring event was edited via "this and future occurrences": 1. The note for a previously-cancelled occurrence was re-stamped with `event.updated`, which Google bumps when the series is touched. The thread jumped to the top of activity even though the cancellation was weeks old. Google doesn't tell us when (or by whom) an occurrence was cancelled, so stamp the note with the time the connector first noticed the cancellation, persist it in connector storage, and reuse that timestamp on every subsequent sync. Drop the "{organizer} cancelled the … occurrence" prefix — organizer != canceller. 2. The description note (key="description") was overwriting in place on every sync. Edits were lost as history. Key the description note by a content hash (`description-{sha256-8}`): identical content is an idempotent upsert, edited content produces a new note, and prior versions remain on the thread as history. Stamp `created` with the first time the connector observed each hash so unrelated re-syncs don't drag the description note forward in the activity feed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-20T01:51:08Z

Summary

Two related bugs surfaced when a recurring Google Calendar event was edited via "this and future occurrences":

A previously-cancelled occurrence's note ("… cancelled the March 18 occurrence.") got re-stamped to "now" and bumped the thread to the top of activity. Root cause: the note's created came from event.updated, which Google bumps when the series is touched. Google doesn't actually tell us when (or by whom) an occurrence was cancelled.
A description edit silently overwrote the existing description note instead of recording the change as history.

Changes

Cancellation notes — stamp created with the time the connector first noticed the cancellation (persisted in connector storage via this.set/get) and reuse that timestamp on every subsequent sync. Applied to both occurrence-level (prepareEventInstance) and master-level cancellation paths. Dropped the "{organizer} cancelled …" attribution since event.organizer is the organizer, not the canceller.

Description notes — key is now description-${sha256-8(content)} instead of "description". Identical content is an idempotent upsert; edited content produces a new note while prior versions remain on the thread as history. created is stamped from the first time the connector observed each hash so unrelated re-syncs don't drag the note forward in the activity feed.

Added two small helpers:

hashContent(content) in google-api.ts — SHA-256, first 8 bytes hex.
Connector.firstSeenAt(key) — get-or-stamp pattern over this.set/this.get.

Test plan

On a recurring event with a cancelled occurrence, edit "this and future occurrences" — the existing cancellation note keeps its original timestamp and the thread does not bump.
Cancel a fresh occurrence — a new note appears once, dated at notice time, and does not re-bump on subsequent syncs.
Edit an event description — a new description note appears alongside the prior one (history preserved); re-syncing without further edits is a no-op.
Identical descriptions across users on the same meeting still converge on one shared note (same hash → same key on the shared iCalUID thread).

🤖 Generated with Claude Code

Two related bugs surfaced when a recurring event was edited via "this and future occurrences": 1. The note for a previously-cancelled occurrence was re-stamped with `event.updated`, which Google bumps when the series is touched. The thread jumped to the top of activity even though the cancellation was weeks old. Google doesn't tell us when (or by whom) an occurrence was cancelled, so stamp the note with the time the connector first noticed the cancellation, persist it in connector storage, and reuse that timestamp on every subsequent sync. Drop the "{organizer} cancelled the … occurrence" prefix — organizer != canceller. 2. The description note (key="description") was overwriting in place on every sync. Edits were lost as history. Key the description note by a content hash (`description-{sha256-8}`): identical content is an idempotent upsert, edited content produces a new note, and prior versions remain on the thread as history. Stamp `created` with the first time the connector observed each hash so unrelated re-syncs don't drag the description note forward in the activity feed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-20T01:51:08Z

Summary

Two related bugs surfaced when a recurring Google Calendar event was edited via "this and future occurrences":

A previously-cancelled occurrence's note ("… cancelled the March 18 occurrence.") got re-stamped to "now" and bumped the thread to the top of activity. Root cause: the note's created came from event.updated, which Google bumps when the series is touched. Google doesn't actually tell us when (or by whom) an occurrence was cancelled.
A description edit silently overwrote the existing description note instead of recording the change as history.

Changes

Cancellation notes — stamp created with the time the connector first noticed the cancellation (persisted in connector storage via this.set/get) and reuse that timestamp on every subsequent sync. Applied to both occurrence-level (prepareEventInstance) and master-level cancellation paths. Dropped the "{organizer} cancelled …" attribution since event.organizer is the organizer, not the canceller.

Description notes — key is now description-${sha256-8(content)} instead of "description". Identical content is an idempotent upsert; edited content produces a new note while prior versions remain on the thread as history. created is stamped from the first time the connector observed each hash so unrelated re-syncs don't drag the note forward in the activity feed.

Added two small helpers:

hashContent(content) in google-api.ts — SHA-256, first 8 bytes hex.
Connector.firstSeenAt(key) — get-or-stamp pattern over this.set/this.get.

Test plan

On a recurring event with a cancelled occurrence, edit "this and future occurrences" — the existing cancellation note keeps its original timestamp and the thread does not bump.
Cancel a fresh occurrence — a new note appears once, dated at notice time, and does not re-bump on subsequent syncs.
Edit an event description — a new description note appears alongside the prior one (history preserved); re-syncing without further edits is a no-op.
Identical descriptions across users on the same meeting still converge on one shared note (same hash → same key on the shared iCalUID thread).

🤖 Generated with Claude Code

Two related bugs surfaced when a recurring event was edited via "this and future occurrences": 1. The note for a previously-cancelled occurrence was re-stamped with `event.updated`, which Google bumps when the series is touched. The thread jumped to the top of activity even though the cancellation was weeks old. Google doesn't tell us when (or by whom) an occurrence was cancelled, so stamp the note with the time the connector first noticed the cancellation, persist it in connector storage, and reuse that timestamp on every subsequent sync. Drop the "{organizer} cancelled the … occurrence" prefix — organizer != canceller. 2. The description note (key="description") was overwriting in place on every sync. Edits were lost as history. Key the description note by a content hash (`description-{sha256-8}`): identical content is an idempotent upsert, edited content produces a new note, and prior versions remain on the thread as history. Stamp `created` with the first time the connector observed each hash so unrelated re-syncs don't drag the description note forward in the activity feed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-20T01:51:08Z

Summary

Two related bugs surfaced when a recurring Google Calendar event was edited via "this and future occurrences":

A previously-cancelled occurrence's note ("… cancelled the March 18 occurrence.") got re-stamped to "now" and bumped the thread to the top of activity. Root cause: the note's created came from event.updated, which Google bumps when the series is touched. Google doesn't actually tell us when (or by whom) an occurrence was cancelled.
A description edit silently overwrote the existing description note instead of recording the change as history.

Changes

Cancellation notes — stamp created with the time the connector first noticed the cancellation (persisted in connector storage via this.set/get) and reuse that timestamp on every subsequent sync. Applied to both occurrence-level (prepareEventInstance) and master-level cancellation paths. Dropped the "{organizer} cancelled …" attribution since event.organizer is the organizer, not the canceller.

Description notes — key is now description-${sha256-8(content)} instead of "description". Identical content is an idempotent upsert; edited content produces a new note while prior versions remain on the thread as history. created is stamped from the first time the connector observed each hash so unrelated re-syncs don't drag the note forward in the activity feed.

Added two small helpers:

hashContent(content) in google-api.ts — SHA-256, first 8 bytes hex.
Connector.firstSeenAt(key) — get-or-stamp pattern over this.set/this.get.

Test plan

On a recurring event with a cancelled occurrence, edit "this and future occurrences" — the existing cancellation note keeps its original timestamp and the thread does not bump.
Cancel a fresh occurrence — a new note appears once, dated at notice time, and does not re-bump on subsequent syncs.
Edit an event description — a new description note appears alongside the prior one (history preserved); re-syncing without further edits is a no-op.
Identical descriptions across users on the same meeting still converge on one shared note (same hash → same key on the shared iCalUID thread).

🤖 Generated with Claude Code

Two related bugs surfaced when a recurring event was edited via "this and future occurrences": 1. The note for a previously-cancelled occurrence was re-stamped with `event.updated`, which Google bumps when the series is touched. The thread jumped to the top of activity even though the cancellation was weeks old. Google doesn't tell us when (or by whom) an occurrence was cancelled, so stamp the note with the time the connector first noticed the cancellation, persist it in connector storage, and reuse that timestamp on every subsequent sync. Drop the "{organizer} cancelled the … occurrence" prefix — organizer != canceller. 2. The description note (key="description") was overwriting in place on every sync. Edits were lost as history. Key the description note by a content hash (`description-{sha256-8}`): identical content is an idempotent upsert, edited content produces a new note, and prior versions remain on the thread as history. Stamp `created` with the first time the connector observed each hash so unrelated re-syncs don't drag the description note forward in the activity feed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-20T01:51:08Z

Summary

Two related bugs surfaced when a recurring Google Calendar event was edited via "this and future occurrences":

A previously-cancelled occurrence's note ("… cancelled the March 18 occurrence.") got re-stamped to "now" and bumped the thread to the top of activity. Root cause: the note's created came from event.updated, which Google bumps when the series is touched. Google doesn't actually tell us when (or by whom) an occurrence was cancelled.
A description edit silently overwrote the existing description note instead of recording the change as history.

Changes

Cancellation notes — stamp created with the time the connector first noticed the cancellation (persisted in connector storage via this.set/get) and reuse that timestamp on every subsequent sync. Applied to both occurrence-level (prepareEventInstance) and master-level cancellation paths. Dropped the "{organizer} cancelled …" attribution since event.organizer is the organizer, not the canceller.

Description notes — key is now description-${sha256-8(content)} instead of "description". Identical content is an idempotent upsert; edited content produces a new note while prior versions remain on the thread as history. created is stamped from the first time the connector observed each hash so unrelated re-syncs don't drag the note forward in the activity feed.

Added two small helpers:

hashContent(content) in google-api.ts — SHA-256, first 8 bytes hex.
Connector.firstSeenAt(key) — get-or-stamp pattern over this.set/this.get.

Test plan

On a recurring event with a cancelled occurrence, edit "this and future occurrences" — the existing cancellation note keeps its original timestamp and the thread does not bump.
Cancel a fresh occurrence — a new note appears once, dated at notice time, and does not re-bump on subsequent syncs.
Edit an event description — a new description note appears alongside the prior one (history preserved); re-syncing without further edits is a no-op.
Identical descriptions across users on the same meeting still converge on one shared note (same hash → same key on the shared iCalUID thread).

🤖 Generated with Claude Code

Two related bugs surfaced when a recurring event was edited via "this and future occurrences": 1. The note for a previously-cancelled occurrence was re-stamped with `event.updated`, which Google bumps when the series is touched. The thread jumped to the top of activity even though the cancellation was weeks old. Google doesn't tell us when (or by whom) an occurrence was cancelled, so stamp the note with the time the connector first noticed the cancellation, persist it in connector storage, and reuse that timestamp on every subsequent sync. Drop the "{organizer} cancelled the … occurrence" prefix — organizer != canceller. 2. The description note (key="description") was overwriting in place on every sync. Edits were lost as history. Key the description note by a content hash (`description-{sha256-8}`): identical content is an idempotent upsert, edited content produces a new note, and prior versions remain on the thread as history. Stamp `created` with the first time the connector observed each hash so unrelated re-syncs don't drag the description note forward in the activity feed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-20T01:51:08Z

Summary

Two related bugs surfaced when a recurring Google Calendar event was edited via "this and future occurrences":

A previously-cancelled occurrence's note ("… cancelled the March 18 occurrence.") got re-stamped to "now" and bumped the thread to the top of activity. Root cause: the note's created came from event.updated, which Google bumps when the series is touched. Google doesn't actually tell us when (or by whom) an occurrence was cancelled.
A description edit silently overwrote the existing description note instead of recording the change as history.

Changes

Cancellation notes — stamp created with the time the connector first noticed the cancellation (persisted in connector storage via this.set/get) and reuse that timestamp on every subsequent sync. Applied to both occurrence-level (prepareEventInstance) and master-level cancellation paths. Dropped the "{organizer} cancelled …" attribution since event.organizer is the organizer, not the canceller.

Description notes — key is now description-${sha256-8(content)} instead of "description". Identical content is an idempotent upsert; edited content produces a new note while prior versions remain on the thread as history. created is stamped from the first time the connector observed each hash so unrelated re-syncs don't drag the note forward in the activity feed.

Added two small helpers:

hashContent(content) in google-api.ts — SHA-256, first 8 bytes hex.
Connector.firstSeenAt(key) — get-or-stamp pattern over this.set/this.get.

Test plan

On a recurring event with a cancelled occurrence, edit "this and future occurrences" — the existing cancellation note keeps its original timestamp and the thread does not bump.
Cancel a fresh occurrence — a new note appears once, dated at notice time, and does not re-bump on subsequent syncs.
Edit an event description — a new description note appears alongside the prior one (history preserved); re-syncing without further edits is a no-op.
Identical descriptions across users on the same meeting still converge on one shared note (same hash → same key on the shared iCalUID thread).

🤖 Generated with Claude Code

Two related bugs surfaced when a recurring event was edited via "this and future occurrences": 1. The note for a previously-cancelled occurrence was re-stamped with `event.updated`, which Google bumps when the series is touched. The thread jumped to the top of activity even though the cancellation was weeks old. Google doesn't tell us when (or by whom) an occurrence was cancelled, so stamp the note with the time the connector first noticed the cancellation, persist it in connector storage, and reuse that timestamp on every subsequent sync. Drop the "{organizer} cancelled the … occurrence" prefix — organizer != canceller. 2. The description note (key="description") was overwriting in place on every sync. Edits were lost as history. Key the description note by a content hash (`description-{sha256-8}`): identical content is an idempotent upsert, edited content produces a new note, and prior versions remain on the thread as history. Stamp `created` with the first time the connector observed each hash so unrelated re-syncs don't drag the description note forward in the activity feed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-20T01:51:08Z

Summary

Two related bugs surfaced when a recurring Google Calendar event was edited via "this and future occurrences":

A previously-cancelled occurrence's note ("… cancelled the March 18 occurrence.") got re-stamped to "now" and bumped the thread to the top of activity. Root cause: the note's created came from event.updated, which Google bumps when the series is touched. Google doesn't actually tell us when (or by whom) an occurrence was cancelled.
A description edit silently overwrote the existing description note instead of recording the change as history.

Changes

Cancellation notes — stamp created with the time the connector first noticed the cancellation (persisted in connector storage via this.set/get) and reuse that timestamp on every subsequent sync. Applied to both occurrence-level (prepareEventInstance) and master-level cancellation paths. Dropped the "{organizer} cancelled …" attribution since event.organizer is the organizer, not the canceller.

Description notes — key is now description-${sha256-8(content)} instead of "description". Identical content is an idempotent upsert; edited content produces a new note while prior versions remain on the thread as history. created is stamped from the first time the connector observed each hash so unrelated re-syncs don't drag the note forward in the activity feed.

Added two small helpers:

hashContent(content) in google-api.ts — SHA-256, first 8 bytes hex.
Connector.firstSeenAt(key) — get-or-stamp pattern over this.set/this.get.

Test plan

On a recurring event with a cancelled occurrence, edit "this and future occurrences" — the existing cancellation note keeps its original timestamp and the thread does not bump.
Cancel a fresh occurrence — a new note appears once, dated at notice time, and does not re-bump on subsequent syncs.
Edit an event description — a new description note appears alongside the prior one (history preserved); re-syncing without further edits is a no-op.
Identical descriptions across users on the same meeting still converge on one shared note (same hash → same key on the shared iCalUID thread).

🤖 Generated with Claude Code

Two related bugs surfaced when a recurring event was edited via "this and future occurrences": 1. The note for a previously-cancelled occurrence was re-stamped with `event.updated`, which Google bumps when the series is touched. The thread jumped to the top of activity even though the cancellation was weeks old. Google doesn't tell us when (or by whom) an occurrence was cancelled, so stamp the note with the time the connector first noticed the cancellation, persist it in connector storage, and reuse that timestamp on every subsequent sync. Drop the "{organizer} cancelled the … occurrence" prefix — organizer != canceller. 2. The description note (key="description") was overwriting in place on every sync. Edits were lost as history. Key the description note by a content hash (`description-{sha256-8}`): identical content is an idempotent upsert, edited content produces a new note, and prior versions remain on the thread as history. Stamp `created` with the first time the connector observed each hash so unrelated re-syncs don't drag the description note forward in the activity feed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-20T01:51:08Z

Summary

Two related bugs surfaced when a recurring Google Calendar event was edited via "this and future occurrences":

A previously-cancelled occurrence's note ("… cancelled the March 18 occurrence.") got re-stamped to "now" and bumped the thread to the top of activity. Root cause: the note's created came from event.updated, which Google bumps when the series is touched. Google doesn't actually tell us when (or by whom) an occurrence was cancelled.
A description edit silently overwrote the existing description note instead of recording the change as history.

Changes

Cancellation notes — stamp created with the time the connector first noticed the cancellation (persisted in connector storage via this.set/get) and reuse that timestamp on every subsequent sync. Applied to both occurrence-level (prepareEventInstance) and master-level cancellation paths. Dropped the "{organizer} cancelled …" attribution since event.organizer is the organizer, not the canceller.

Description notes — key is now description-${sha256-8(content)} instead of "description". Identical content is an idempotent upsert; edited content produces a new note while prior versions remain on the thread as history. created is stamped from the first time the connector observed each hash so unrelated re-syncs don't drag the note forward in the activity feed.

Added two small helpers:

hashContent(content) in google-api.ts — SHA-256, first 8 bytes hex.
Connector.firstSeenAt(key) — get-or-stamp pattern over this.set/this.get.

Test plan

On a recurring event with a cancelled occurrence, edit "this and future occurrences" — the existing cancellation note keeps its original timestamp and the thread does not bump.
Cancel a fresh occurrence — a new note appears once, dated at notice time, and does not re-bump on subsequent syncs.
Edit an event description — a new description note appears alongside the prior one (history preserved); re-syncing without further edits is a no-op.
Identical descriptions across users on the same meeting still converge on one shared note (same hash → same key on the shared iCalUID thread).

🤖 Generated with Claude Code

Two related bugs surfaced when a recurring event was edited via "this and future occurrences": 1. The note for a previously-cancelled occurrence was re-stamped with `event.updated`, which Google bumps when the series is touched. The thread jumped to the top of activity even though the cancellation was weeks old. Google doesn't tell us when (or by whom) an occurrence was cancelled, so stamp the note with the time the connector first noticed the cancellation, persist it in connector storage, and reuse that timestamp on every subsequent sync. Drop the "{organizer} cancelled the … occurrence" prefix — organizer != canceller. 2. The description note (key="description") was overwriting in place on every sync. Edits were lost as history. Key the description note by a content hash (`description-{sha256-8}`): identical content is an idempotent upsert, edited content produces a new note, and prior versions remain on the thread as history. Stamp `created` with the first time the connector observed each hash so unrelated re-syncs don't drag the description note forward in the activity feed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun merged commit c81d735 into mainMay 20, 2026
1 check passed

KrisBraun deleted the fix/calendar-cancellation-and-description-history branch May 20, 2026 01:54