[Feature] Reconcile tentative Calendar holds after Scheduling completion #6

New Issue

zemion · 2026-07-22T08:03:13+02:00

zemion commented

2026-07-22 08:03:13 +02:00

User Need

When a Scheduling request is decided or cancelled, tentative Calendar holds must not remain as misleading blockers. The selected hold should be promoted or replaced by the confirmed event, while non-selected holds should be released through Calendar-owned durable operations.

Acceptance Criteria

Extend the optional Core calendar.scheduling contract with an idempotent, tenant-scoped event cancellation/release operation; Scheduling must not import Calendar internals.
Calendar implements release through its durable outbox, including retry, reconciliation, audit metadata, and already-deleted/not-found idempotency.
On decision, Scheduling records cleanup intent for every non-selected tentative hold and never reports completion before Calendar accepts each durable operation.
If the selected slot already has a tentative hold, define and implement an idempotent promotion/update path or explicitly replace it before creating the confirmed event.
On cancellation, Scheduling releases all tentative holds.
Partial failures remain visible and retryable without duplicating Calendar effects; slot metadata retains operation identifiers and last-known state only.
Tests cover decision, cancellation, exact retries, partial Calendar failure, absent Calendar capability, and eventual reconciliation.
The Scheduling handbook explains cleanup state and recovery.

Context

Split from scheduling#3. Creating holds and the confirmed event is implemented, but the current Calendar capability exposes only free/busy and create-event operations. Destructive remote effects must remain Calendar-owned and outbox-backed.

## User Need When a Scheduling request is decided or cancelled, tentative Calendar holds must not remain as misleading blockers. The selected hold should be promoted or replaced by the confirmed event, while non-selected holds should be released through Calendar-owned durable operations. ## Acceptance Criteria - Extend the optional Core `calendar.scheduling` contract with an idempotent, tenant-scoped event cancellation/release operation; Scheduling must not import Calendar internals. - Calendar implements release through its durable outbox, including retry, reconciliation, audit metadata, and already-deleted/not-found idempotency. - On decision, Scheduling records cleanup intent for every non-selected tentative hold and never reports completion before Calendar accepts each durable operation. - If the selected slot already has a tentative hold, define and implement an idempotent promotion/update path or explicitly replace it before creating the confirmed event. - On cancellation, Scheduling releases all tentative holds. - Partial failures remain visible and retryable without duplicating Calendar effects; slot metadata retains operation identifiers and last-known state only. - Tests cover decision, cancellation, exact retries, partial Calendar failure, absent Calendar capability, and eventual reconciliation. - The Scheduling handbook explains cleanup state and recovery. ## Context Split from scheduling#3. Creating holds and the confirmed event is implemented, but the current Calendar capability exposes only free/busy and create-event operations. Destructive remote effects must remain Calendar-owned and outbox-backed.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-scheduling#6