# Research: Cancel Event from Event List

**Date**: 2026-03-12 | **Branch**: `018-cancel-event-list`

## Existing Cancel-Event API

- **Decision**: Reuse the existing `PATCH /events/{eventToken}?organizerToken=...` endpoint with `{ cancelled: true }` body.
- **Rationale**: The endpoint is fully implemented and documented in the OpenAPI spec. The EventDetailView already calls it successfully. No backend changes needed.
- **Alternatives considered**: None — the endpoint exists and fits the requirement exactly.

## EventList Delete Flow Architecture

- **Decision**: Extend the existing `confirmDelete()` handler in `EventList.vue` with a role-based branch: organizer → PATCH cancel-event, attendee → DELETE cancel-rsvp, watcher → direct remove.
- **Rationale**: The role detection (`getRole()`) already exists (lines 113-117). The current handler only covers attendee (RSVP deletion) and watcher (direct remove). Adding the organizer branch follows the same pattern.
- **Alternatives considered**: Creating a separate handler for organizer cancel — rejected because it would duplicate the dialog open/close and error handling logic.

## ConfirmDialog Message Differentiation

- **Decision**: Compute `deleteDialogMessage` and `deleteDialogTitle` based on `getRole(pendingDeleteEvent)`. Organizer gets a severe warning ("Cancel event? This will cancel the event for all attendees."), attendee keeps existing message.
- **Rationale**: The ConfirmDialog already accepts `title` and `message` props. The `deleteDialogMessage` computed property exists but currently only distinguishes RSVP vs watcher. Extend it to include organizer.
- **Alternatives considered**: Using a different dialog component for organizer — rejected (unnecessary, ConfirmDialog is sufficient and already styled with danger button).

## 409 Conflict Handling

- **Decision**: Treat 409 (event already cancelled) as success — silently remove event from local list.
- **Rationale**: Frontend does not track cancelled status. If the server says it's already cancelled, the user's intent (remove from list) is fulfilled either way.
- **Alternatives considered**: Showing an info message ("Event was already cancelled") — rejected per clarification session, silent removal is simpler and less confusing.

## In-Flight Behavior

- **Decision**: No loading indicator in ConfirmDialog. Dialog stays open until success (close + remove) or failure (stay open + error).
- **Rationale**: Consistent with all other ConfirmDialog-based flows in the project (cancel RSVP, delete event from list). The ConfirmDialog component has no loading state support and adding one would be scope creep.
- **Alternatives considered**: Adding `:disabled` + spinner to confirm button (like BottomSheet forms) — rejected for consistency with existing ConfirmDialog patterns.

## Confirm Button Styling

- **Decision**: Use `var(--color-danger-solid)` for the organizer cancel confirm button, consistent with existing ConfirmDialog danger styling.
- **Rationale**: The ConfirmDialog already uses danger-colored confirm buttons. No additional styling needed for the organizer flow.
- **Alternatives considered**: None — existing styling fits.