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

New Issue

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.

zemion added the area/api codex/ready module/scheduling

labels 2026-07-29 14:15:01 +02:00

zemion commented

2026-08-20 07:45:28 +02:00

Implemented and pushed tentative Calendar hold reconciliation across the neutral Core contract, Calendar, and Scheduling. Core 0fae09b adds promote/release DTOs and protocol methods; Calendar 93fb8ae provides tenant-scoped in-place promotion plus idempotent release through its existing durable synchronization outbox; Scheduling 79cfaa9 promotes the selected hold, releases unused holds on decision/cancellation, retains bounded retry state after partial failures, supports replay without duplicate final events, exposes pending cleanup in the UI, and documents operator/user consequences. Verification: Calendar 144 tests; Scheduling 77 tests; Core module-system 128 tests; manifest registry 68/68; static contracts and dependency boundaries; full focused gate including 57 WebUI permutations, full-product build/bundle budgets, and 7 Playwright conformance tests. All passed.

Implemented and pushed tentative Calendar hold reconciliation across the neutral Core contract, Calendar, and Scheduling. Core 0fae09b adds promote/release DTOs and protocol methods; Calendar 93fb8ae provides tenant-scoped in-place promotion plus idempotent release through its existing durable synchronization outbox; Scheduling 79cfaa9 promotes the selected hold, releases unused holds on decision/cancellation, retains bounded retry state after partial failures, supports replay without duplicate final events, exposes pending cleanup in the UI, and documents operator/user consequences. Verification: Calendar 144 tests; Scheduling 77 tests; Core module-system 128 tests; manifest registry 68/68; static contracts and dependency boundaries; full focused gate including 57 WebUI permutations, full-product build/bundle budgets, and 7 Playwright conformance tests. All passed.

zemion closed this issue

2026-08-20 07:45:28 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-scheduling#6