funman300/Ferrous-Solitaire
1
1
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 48 Wiki Activity

fix(server): delete analytics_events rows on account deletion #142

New Issue
Closed
opened 2026-07-07 03:06:04 +00:00 by funman300 · 1 comment
funman300 commented 2026-07-07 03:06:04 +00:00
Owner
Copy Link
Copy Source

Review finding L4 (2026-07-06). analytics_events.user_id has no FK/cascade (004_analytics.sql), so a deleted account's analytics rows persist forever while every other user table cascades. Privacy nit. Fix options: add a DELETE FROM analytics_events WHERE user_id = ? to delete_account, or (preferred, keeps aggregate stats) anonymise: UPDATE analytics_events SET user_id = NULL WHERE user_id = ?. Migrations are append-only, so don't retrofit an FK — handle it in the handler.

🤖 Generated with Claude Code

Review finding L4 (2026-07-06). `analytics_events.user_id` has no FK/cascade (004_analytics.sql), so a deleted account's analytics rows persist forever while every other user table cascades. Privacy nit. Fix options: add a `DELETE FROM analytics_events WHERE user_id = ?` to `delete_account`, or (preferred, keeps aggregate stats) anonymise: `UPDATE analytics_events SET user_id = NULL WHERE user_id = ?`. Migrations are append-only, so don't retrofit an FK — handle it in the handler. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
funman300 commented 2026-07-07 03:15:19 +00:00
Author
Owner
Copy Link
Copy Source

Investigated before fixing: nothing in the workspace reads or writes analytics_events — no server route ingests it and the client ships events to the external Matomo instance (analytics.aleshym.co) via MatomoClient. The table from migration 004 is dead scaffolding with zero rows in practice, so there is no user data to clean up on account deletion and the handler fix would touch a table that is never written. Remaining decision (schema change, needs owner sign-off per CLAUDE.md §8): add a migration 006 dropping the unused table, or leave it dormant. Closing as no-user-data-at-risk; reopen if analytics ingest is ever wired server-side.

Investigated before fixing: nothing in the workspace reads or writes analytics_events — no server route ingests it and the client ships events to the external Matomo instance (analytics.aleshym.co) via MatomoClient. The table from migration 004 is dead scaffolding with zero rows in practice, so there is no user data to clean up on account deletion and the handler fix would touch a table that is never written. Remaining decision (schema change, needs owner sign-off per CLAUDE.md §8): add a migration 006 dropping the unused table, or leave it dormant. Closing as no-user-data-at-risk; reopen if analytics ingest is ever wired server-side.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
android
bug
correctness
enhancement
performance
security
server
test
ui
ux
wasm
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
funman300 (Alex)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: funman300/Ferrous-Solitaire#142
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?