Event Lifecycle
Overview
Section titled “Overview”Events and gigs share the same Event entity distinguished by the type field (EVENT or GIG). Both follow the same CRUD operations and status lifecycle. External events (from OSU API or Ticketmaster) behave identically to user-created events except they cannot be created, updated, or deleted by users.
Status Lifecycle
Section titled “Status Lifecycle”OPEN ──► IN_PROGRESS ──► COMPLETED │ ▲ │ │ ├──────────► CANCELLED │ (auto: endAt passes) │ │ └──► IN_PROGRESS ─────────────┘- OPEN: Default status on creation. The event is visible and active.
- IN_PROGRESS: The event or gig is currently happening or work has started.
- COMPLETED: The event has ended or the gig work is finished.
- CANCELLED: The creator cancelled the event/gig.
Auto-Completion
Section titled “Auto-Completion”A scheduled Cloudflare Worker cron trigger runs every 15 minutes. It queries all events where endAt is in the past and status is not COMPLETED or CANCELLED, then sets their status to COMPLETED. The creator can also manually mark an event as COMPLETED before endAt.
If an event has no endAt, it is never auto-completed — the creator must complete it manually.
Creation
Section titled “Creation”Event Creation
Section titled “Event Creation”Any authenticated user can create an event with type EVENT. Required fields: title, description, location, startAt. The source is set to USER and creatorId to the authenticated user.
On creation, the system attempts to auto-generate tags, summary, and category using AI tagging. If the AI service is unavailable or times out, the event is still created with tags as an empty array and summary/category as null. AI tagging failure does not block event creation.
Gig Creation
Section titled “Gig Creation”Same as event creation but with type GIG. The compensation field is available for gigs.
Scenarios
Section titled “Scenarios”S-EVT-1: Create an event
Section titled “S-EVT-1: Create an event”GIVEN user A is authenticatedWHEN user A sends POST /events with { title: "Hackathon", description: "24hr hackathon", type: "EVENT", location: { name: "Ohio Union" }, startAt: "2025-04-01T09:00:00Z" }THEN an Event is created with status OPEN, source USER, creatorId = user A's idAND the system generates tags for the eventS-EVT-2: Create a gig
Section titled “S-EVT-2: Create a gig”GIVEN user A is authenticatedWHEN user A sends POST /events with { title: "Need a tutor", description: "Calculus tutor needed", type: "GIG", location: { name: "Thompson Library" }, startAt: "2025-04-05T14:00:00Z", compensation: { amount: 25, currency: "USD", type: "HOURLY" } }THEN an Event is created with type GIG, status OPEN, compensation { amount: 25, currency: "USD", type: "HOURLY" }S-EVT-3: Read single event
Section titled “S-EVT-3: Read single event”GIVEN event E existsWHEN any authenticated user sends GET /events/ETHEN the response contains the full event detailsS-EVT-4: List events with filters
Section titled “S-EVT-4: List events with filters”GIVEN events exist with various types, categories, and datesWHEN a user sends GET /events?type=EVENT&category=music&startDate=2025-04-01THEN the response contains only events matching all filtersAND results are paginated with limit and offset paramsS-EVT-5: Update own event
Section titled “S-EVT-5: Update own event”GIVEN user A created event E with title "Hackathon"WHEN user A sends PATCH /events/E with { title: "Mega Hackathon" }THEN event E's title is "Mega Hackathon"S-EVT-6: Delete own event
Section titled “S-EVT-6: Delete own event”GIVEN user A created event EWHEN user A sends DELETE /events/ETHEN event E is removed from the systemS-EVT-7: Cannot modify external event
Section titled “S-EVT-7: Cannot modify external event”GIVEN event E has source OSU_APIWHEN any user sends PATCH /events/E or DELETE /events/ETHEN the API responds with 403 ForbiddenS-EVT-8: Cancel an event
Section titled “S-EVT-8: Cancel an event”GIVEN user A created event E with status OPENWHEN user A sends PATCH /events/E with { status: "CANCELLED" }THEN event E's status is CANCELLEDS-EVT-9: Manual completion
Section titled “S-EVT-9: Manual completion”GIVEN user A created event E with status IN_PROGRESSWHEN user A sends PATCH /events/E with { status: "COMPLETED" }THEN event E's status is COMPLETEDS-EVT-10: Auto-completion after endAt
Section titled “S-EVT-10: Auto-completion after endAt”GIVEN event E has status OPEN and endAt "2025-04-01T18:00:00Z"WHEN the auto-completion cron runs after "2025-04-01T18:00:00Z"THEN event E's status is set to COMPLETEDS-EVT-11: No auto-completion without endAt
Section titled “S-EVT-11: No auto-completion without endAt”GIVEN event E has status OPEN and endAt is nullWHEN the auto-completion cron runsTHEN event E's status remains OPENS-EVT-12: AI auto-tagging on creation
Section titled “S-EVT-12: AI auto-tagging on creation”GIVEN user A creates an event with title "Jazz Night at the Union" and description "Live jazz performance featuring student musicians"WHEN the event is savedTHEN the system generates tags such as ["jazz", "music", "live-performance", "student"]AND generates a category such as "music"AND generates a short summaryS-EVT-13: AI tagging failure does not block creation
Section titled “S-EVT-13: AI tagging failure does not block creation”GIVEN the AI service is unavailableWHEN user A creates an eventTHEN the event is created with tags = [], summary = null, category = nullAND the API responds with 201 (not an error)S-EVT-14: Delete event cascades
Section titled “S-EVT-14: Delete event cascades”GIVEN user A created event EAND event E has 3 applications, 5 interactions, and appears in 2 collectionsWHEN user A sends DELETE /events/ETHEN event E, its 3 applications, 5 interactions, and 2 collection items are all deletedS-EVT-15: Filter events by source
Section titled “S-EVT-15: Filter events by source”GIVEN events exist from sources USER, OSU_API, and TICKETMASTERWHEN a user sends GET /events?source=TICKETMASTERTHEN the response contains only events with source TICKETMASTERS-EVT-16: Update gig after applications exist
Section titled “S-EVT-16: Update gig after applications exist”GIVEN user A created gig G with compensation { amount: 20, type: "HOURLY" }AND gig G has 2 pending applicationsWHEN user A sends PATCH /events/G with { compensation: { amount: 25, type: "HOURLY" } }THEN gig G's compensation amount is updated to 25AND existing applications are not affected