The fake cascade does not clear dimension rows, so ordering constraints cannot be tested #19

New Issue

GKaszewski · 2026-08-26T11:23:36Z

GKaszewski commented

2026-08-26 11:23:36 +00:00

What to build

InMemoryStore's CascadeDeletePort removes entries but leaves dimension values behind. Real SQLite removes them via ON DELETE CASCADE. The fake is therefore more forgiving than production, and one real constraint currently has no test because of it.

delete_entries_by_date_range must resolve media before the cascade runs: deleting the entries removes their dimension rows too, so composing afterwards finds nothing and every photo and voice memo blob is orphaned silently. Today that ordering is protected only by the name media_of_entries_about_to_be_deleted. A test written against the fake would pass whichever order the code used, which is worse than no test.

Make the fake cascade clear dimension values for the entries it deletes, then add the test that fails when the order is wrong.

Acceptance criteria

Deleting entries through the fake cascade also clears their dimension values
A test fails if media resolution is moved after the cascade in delete_entries_by_date_range
The same holds for clear_data and delete_user, which have the identical ordering requirement
ON DELETE CASCADE is confirmed to actually fire against a real database — it depends on foreign_keys(true) being set on the pool, without which SQLite ignores it silently

Blocked by

None - can start immediately.

## What to build `InMemoryStore`'s `CascadeDeletePort` removes entries but leaves dimension values behind. Real SQLite removes them via `ON DELETE CASCADE`. The fake is therefore more forgiving than production, and one real constraint currently has no test because of it. `delete_entries_by_date_range` must resolve media **before** the cascade runs: deleting the entries removes their dimension rows too, so composing afterwards finds nothing and every photo and voice memo blob is orphaned silently. Today that ordering is protected only by the name `media_of_entries_about_to_be_deleted`. A test written against the fake would pass whichever order the code used, which is worse than no test. Make the fake cascade clear dimension values for the entries it deletes, then add the test that fails when the order is wrong. ## Acceptance criteria - [ ] Deleting entries through the fake cascade also clears their dimension values - [ ] A test fails if media resolution is moved after the cascade in `delete_entries_by_date_range` - [ ] The same holds for `clear_data` and `delete_user`, which have the identical ordering requirement - [ ] `ON DELETE CASCADE` is confirmed to actually fire against a real database — it depends on `foreign_keys(true)` being set on the pool, without which SQLite ignores it silently ## Blocked by None - can start immediately.

GKaszewski added the ready-for-agent label 2026-08-26 11:23:36 +00:00

GKaszewski closed this issue

2026-08-26 19:07:06 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GKaszewski/k-mood#19