Mock: let an override move an occurrence, as the server does #138

New Issue

Closed

opened 2026-08-31 04:50:06 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-31 04:50:06 +00:00

Owner

Follow-up to #137, from continuing to probe the live 0.16.20 instance for anything else the release changed.

The finding

An override can move an occurrence, and then start and recurrenceId mean two different times — the slot the rule made stays put, and only the clock time moves.

Confirmed live on 0.16.20 (2026-08-31), one occurrence of a weekly 09:00 series moved to 14:00:

{ "start": "2027-06-07T09:00:00", "recurrenceId": "2027-06-07T09:00:00" }
{ "start": "2027-06-14T14:00:00", "recurrenceId": "2027-06-14T09:00:00" }   ← moved
{ "start": "2027-06-21T09:00:00", "recurrenceId": "2027-06-21T09:00:00" }

That is correct behaviour, and it independently confirms the choice of handle made in #137: recurrenceId is the one name for an instance that survives both a renumbering and a move. Keying re-resolution on start would have broken the moment anyone moved an occurrence.

What was wrong

occurrenceView merged the override and then set start from the slot, clobbering any start the override carried. A moved occurrence did not move. So per-occurrence time editing — one of the main things #132 is for — looked broken against the mock and correct against the real server.

That is the wrong way round for a mock to be wrong, and it is the third time in this sequence that asking the server has contradicted something the mock asserted confidently. Recorded in KNOWN-ISSUES on those grounds rather than as a mere bugfix.

Window filtering now tests the occurrence's shown time rather than its slot, so a moved occurrence lands in the range it is actually displayed in.

Tests

Three new cases: the move is applied, recurrenceId stays on the original slot, and the occurrence is still findable by recurrenceId afterwards — that last one being the property the store's re-resolution depends on.

388 web, 109 server (up from 106). Build clean.

Merged 2026-08-30 as coffey-labs/ihasmail@806e63d071

_{Rebuilt from: git history, session transcript.}

Follow-up to #137, from continuing to probe the live 0.16.20 instance for anything else the release changed. ## The finding An override can *move* an occurrence, and then `start` and `recurrenceId` mean two different times — the slot the rule made stays put, and only the clock time moves. **Confirmed live on 0.16.20 (2026-08-31)**, one occurrence of a weekly 09:00 series moved to 14:00: ``` { "start": "2027-06-07T09:00:00", "recurrenceId": "2027-06-07T09:00:00" } { "start": "2027-06-14T14:00:00", "recurrenceId": "2027-06-14T09:00:00" } ← moved { "start": "2027-06-21T09:00:00", "recurrenceId": "2027-06-21T09:00:00" } ``` That is correct behaviour, and it independently confirms the choice of handle made in #137: `recurrenceId` is the one name for an instance that survives **both** a renumbering and a move. Keying re-resolution on `start` would have broken the moment anyone moved an occurrence. ## What was wrong `occurrenceView` merged the override and *then* set `start` from the slot, clobbering any `start` the override carried. A moved occurrence did not move. So per-occurrence **time** editing — one of the main things #132 is for — looked broken against the mock and correct against the real server. That is the wrong way round for a mock to be wrong, and it is the third time in this sequence that asking the server has contradicted something the mock asserted confidently. Recorded in KNOWN-ISSUES on those grounds rather than as a mere bugfix. Window filtering now tests the occurrence's shown time rather than its slot, so a moved occurrence lands in the range it is actually displayed in. ## Tests Three new cases: the move is applied, `recurrenceId` stays on the original slot, and the occurrence is still findable by `recurrenceId` afterwards — that last one being the property the store's re-resolution depends on. 388 web, 109 server (up from 106). Build clean. **Merged** 2026-08-30 as coffey-labs/ihasmail@806e63d0712c <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#138