Same event appears in both "Upcoming" and "Past Events" simultaneously

## What happens The **same event** ("Morning Run", May 8 · 3:17 p.m., South Section) shows up in **both** the "Upcoming" and "Past Events" sections at the same time — see screenshot. The event is the same: same title, same date / time, same location, same tags. But the cards differ: - In **Upcoming** it reads `3/100 going` with a progress bar (forward-looking RSVP UI). - In **Past Events** it reads `3 attended` (retrospective UI). May 8 is still in the future, so the upcoming card is correct. The past-events card is the bug — the event hasn't happened yet, so it shouldn't appear there. ## Where this is The Events / "My Events"-style page that splits events into Upcoming and Past Events lists. ## Expected An event should appear in exactly **one** of the two lists — never both. The split is presumably: - **Upcoming**: events whose end has not yet passed (`end_at >= now`, or fall back to `start_at >= now` when no end). - **Past Events**: events whose end has passed (`end_at < now`). ## Likely root cause (technical) A few candidates worth checking, in rough likelihood order: 1. **End-time fallback is broken.** The list-split logic probably uses `end_at` for the past-cutoff. If the event has no `end_at` (NULL) and the code falls back to a default like `0` / `1970-01-01` instead of `start_at`, the event satisfies both "future" (start_at >= now) and "past" (end_at < now). That's exactly the dual-listing pattern. 2. **Two separate queries with overlapping predicates.** If the Upcoming and Past lists are fetched by two separate API calls (or two separate client-side filters) with non-mutually-exclusive WHERE clauses, an event near the boundary could match both. The two should be defined as a true partition. 3. **Timezone mismatch.** If "now" is computed in different timezones for the two filters (e.g. UTC for Upcoming, local for Past), an event at 3:17 p.m. on a date near "now" can fall on opposite sides of the line. 4. **Two real events with the same title.** Less likely given the perfect match on time + location + tags + RSVP counts (3/100 going vs 3 attended doesn't make sense for two separate events on the same day at the same place), but worth a glance at the IDs in the API response to rule out. ## Investigation steps - DevTools → Network on the page; check whether the Upcoming and Past lists share an event ID. If yes → categorisation bug. If no → two real events. - For the offending event id, check `start_at` and `end_at` in the backend response. If `end_at` is NULL or earlier than `start_at`, that's the fallback bug. - Search the frontend / BFF for the past-events filter predicate; verify it falls back to `start_at` when `end_at` is missing. ## Impact - Confusing UX: users see an event they're going to in their "Past Events" list, may think it already happened and miss it. - Inflates past-event counts — any analytics / badging that relies on past-event count is overstated. ## Found by Manual testing