Skip to content

Fixed SQLite purges with world and block filters purging other tables - #1025

Open
tonyjamesstark wants to merge 1 commit into
PlayPro:masterfrom
tonyjamesstark:fix-sqlite-world-block-purge
Open

tonyjamesstark wants to merge 1 commit into
PlayPro:masterfrom
tonyjamesstark:fix-sqlite-world-block-purge

Conversation

@tonyjamesstark

@tonyjamesstark tonyjamesstark commented Sep 25, 2026 •

Copy link
Copy Markdown

On SQLite, /co purge t:30d r:#world i:stone also deletes rows in co_container, co_chat, co_command, co_session, co_sign and co_item for that world. The block restriction should limit the purge to co_block. MySQL and the entity_container/entity_interaction branch already skip those tables.

Cause: in the SQLite copy step of PurgeCommand, the generic world-scoped branch builds the retain condition without checking purge. Fix: else becomes else if (purge).

To reproduce: on SQLite, log a container transaction and a stone break in one world. Then run /co purge t:<age> r:#<world> i:stone from the console, with a time that covers both. Before the fix, the container row is deleted. After the fix, it stays.

authored and tested with claude

On SQLite, /co purge r:#world i:<block> built the retain condition for
world-scoped tables without checking the block restriction, so it purged
co_container, co_chat and the other world-scoped tables in that world
although a block restriction should leave them untouched. The
entity_container/entity_interaction branch and the MySQL path already
check it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants