A rescheduled session can keep an end time from before its new start #1159

Closed
opened 2026-10-13 01:14:38 +00:00 by claude-bot · 0 comments
Collaborator

What happened

On prod, A Merry Band of Thieves session 14 ("Smudged Maps and Soft Beds") was rescheduled on 27 Sep (under 4.4.1) from 22 Sep to 13 Oct. Its row now reads:

  • confirmed_time 2026-10-14 01:00 UTC
  • end_time 2026-09-23 04:00 UTC

The calendar item shows the right start and an end three weeks earlier. It is the only such row on prod (checked 12 Oct: end_time <= confirmed_time or more than 12 h after it).

Cause

4.4.1's update_session set confirmed_time on reschedule_time and left end_time alone. 4.5.0's move code (session_service.update_session → _apply_move / _put_at) carries the length across, so a confirmed session moved today is right. What is left:

  1. Rows already wrong. Nothing repairs them.
  2. The pencilled path. A session with no confirmed time moves through proposed_times: [iso] (SessionPage.jsx move), which does not touch end_time. Verify; if it can leave an end before the start, fix it the same way.
  3. Readers trust a bad end. calendar_service._build_vevent (and the second reader near line 264), the frontend components/session/calendar.jsx, and worst, the poller in reminder_tasks.py (in_progress → completed when end_time < now): a session whose end is in the past completes within a minute of starting, on the night.

Intended fix (4.5.1)

  • A migration that repairs every session with confirmed_time set and end_time <= confirmed_time: series sessions take the series length, others have end_time cleared (the default length then applies). Real downgrade() is a no-op with a comment (data repair).
  • Close the pencilled path if it is open.
  • Readers ignore an end that is not after the start: calendar feed and invite fall back to the default length; the poller does not complete on it (the 8 h rule still applies).
  • Refuse end_time <= start on write (422, {"detail": ...}).
  • Tests for each.

Session 14's row on prod needs correcting by hand before Tuesday's session, on the owner's say.

## What happened On prod, A Merry Band of Thieves session 14 ("Smudged Maps and Soft Beds") was rescheduled on 27 Sep (under 4.4.1) from 22 Sep to 13 Oct. Its row now reads: - `confirmed_time` 2026-10-14 01:00 UTC - `end_time` 2026-09-23 04:00 UTC The calendar item shows the right start and an end three weeks earlier. It is the only such row on prod (checked 12 Oct: `end_time <= confirmed_time` or more than 12 h after it). ## Cause 4.4.1's `update_session` set `confirmed_time` on `reschedule_time` and left `end_time` alone. 4.5.0's move code (`session_service.update_session` → `_apply_move` / `_put_at`) carries the length across, so a confirmed session moved today is right. What is left: 1. **Rows already wrong.** Nothing repairs them. 2. **The pencilled path.** A session with no confirmed time moves through `proposed_times: [iso]` (`SessionPage.jsx` `move`), which does not touch `end_time`. Verify; if it can leave an end before the start, fix it the same way. 3. **Readers trust a bad end.** `calendar_service._build_vevent` (and the second reader near line 264), the frontend `components/session/calendar.jsx`, and worst, the poller in `reminder_tasks.py` (`in_progress → completed` when `end_time < now`): a session whose end is in the past completes within a minute of starting, on the night. ## Intended fix (4.5.1) - A migration that repairs every session with `confirmed_time` set and `end_time <= confirmed_time`: series sessions take the series length, others have `end_time` cleared (the default length then applies). Real `downgrade()` is a no-op with a comment (data repair). - Close the pencilled path if it is open. - Readers ignore an end that is not after the start: calendar feed and invite fall back to the default length; the poller does not complete on it (the 8 h rule still applies). - Refuse `end_time <= start` on write (422, `{"detail": ...}`). - Tests for each. Session 14's row on prod needs correcting by hand before Tuesday's session, on the owner's say.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board#1159
No description provided.