Calendar settings: failed format saves leave unsaved choices selected #772

Open
opened 2026-10-02 13:10:15 +00:00 by kayg · 2 comments
Owner

Found during the source review for #427 on origin/dev at c4a61e8cf090170f35b1bed3350d9de20c83ecd5.

Decided behavior

DESIGN §35 (per-User synced preferences), §50 (one setting home), and the owner UX completeness rule of 2026-10-02 require real, consistent error and offline states.

Evidence

apps/web/src/routes/settings/calendars/CalendarsSection.svelte:86–94 sets selectedDateFormat, selectedTimeFormat or selectedFirstDay before savePreferences. On failure it shows a toast but does not reset those fields. Lines 73–75 prefer them over confirmed preferences.data. Lines 270–297 render the selected values. The neighboring photo and dragging handlers at lines 97–127 do restore confirmed state on failure.

Observed behavior

A failed save leaves the control showing an unsaved choice. The formatter and persisted preference can still use the previous choice, so Settings describes a state the server did not accept.

This is a source finding. No production build or live-server run was made in this review job.

Expected

Restore the last confirmed value on failure and prevent a stale response from replacing a newer successful choice. Keep the control, shared preview, Calendar and saved preference consistent. Give the User a plain error and a working retry path.

Test idea

Fail one save for each format control and check that it returns to the confirmed choice and matches the preview. Then delay two requests and resolve them out of order. Check the same state after reopening Settings.

For UI evidence, use a production build at 390, 820 and 1440 px in light and dark, with macOS platform hints. Check pointer, keyboard and touch, plus reduced motion.

Duplicate check

Searched all issue titles for date/time formats and failures. Read closed #179, which adds these settings. #593 covers general visible-effect checks, not this concrete failed-save state.

Found during the source review for #427 on `origin/dev` at `c4a61e8cf090170f35b1bed3350d9de20c83ecd5`. ## Decided behavior DESIGN §35 (per-User synced preferences), §50 (one setting home), and the owner UX completeness rule of 2026-10-02 require real, consistent error and offline states. ## Evidence `apps/web/src/routes/settings/calendars/CalendarsSection.svelte:86–94` sets selectedDateFormat, selectedTimeFormat or selectedFirstDay before savePreferences. On failure it shows a toast but does not reset those fields. Lines 73–75 prefer them over confirmed preferences.data. Lines 270–297 render the selected values. The neighboring photo and dragging handlers at lines 97–127 do restore confirmed state on failure. ## Observed behavior A failed save leaves the control showing an unsaved choice. The formatter and persisted preference can still use the previous choice, so Settings describes a state the server did not accept. This is a source finding. No production build or live-server run was made in this review job. ## Expected Restore the last confirmed value on failure and prevent a stale response from replacing a newer successful choice. Keep the control, shared preview, Calendar and saved preference consistent. Give the User a plain error and a working retry path. ## Test idea Fail one save for each format control and check that it returns to the confirmed choice and matches the preview. Then delay two requests and resolve them out of order. Check the same state after reopening Settings. For UI evidence, use a production build at 390, 820 and 1440 px in light and dark, with macOS platform hints. Check pointer, keyboard and touch, plus reduced motion. ## Duplicate check Searched all issue titles for date/time formats and failures. Read closed #179, which adds these settings. #593 covers general visible-effect checks, not this concrete failed-save state.
Author
Owner

Additional source check: selectedDateFormat, selectedTimeFormat and selectedFirstDay are local overrides that outlive a failed save and mask the confirmed preference. The shared save queue serializes requests, so I will test queued failure and retry instead of relying on out-of-order network completion.

Additional source check: `selectedDateFormat`, `selectedTimeFormat` and `selectedFirstDay` are local overrides that outlive a failed save and mask the confirmed preference. The shared save queue serializes requests, so I will test queued failure and retry instead of relying on out-of-order network completion.
Author
Owner

Fixed #772 in 85c139b87. Each format choice clears only its own current optimistic value after success or failure; an older failure cannot reset a newer selection for that field. The saved preference queue serializes requests, so reverse network completion is not a possible state in this adapter. Regression test covers failed date, time and week-start changes returning to System and shows three user-facing errors. bun run test -- src/routes/settings/calendars/CalendarsSection.svelte.test.ts: passed as part of a two-file Vitest run (2 tests total). Production browser proof and screenshot matrix remain in the final pass.

Fixed #772 in `85c139b87`. Each format choice clears only its own current optimistic value after success or failure; an older failure cannot reset a newer selection for that field. The saved preference queue serializes requests, so reverse network completion is not a possible state in this adapter. Regression test covers failed date, time and week-start changes returning to System and shows three user-facing errors. `bun run test -- src/routes/settings/calendars/CalendarsSection.svelte.test.ts`: passed as part of a two-file Vitest run (2 tests total). Production browser proof and screenshot matrix remain in the final pass.
Sign in to join this conversation.
No labels
No milestone
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
kayg/calternal#772
No description provided.