Repository navigation
Entity radius purge - #1030
Merged
Merged
Entity radius purge#1030
Conversation
co_entity has no world column, so /co purge r:#world deleted the kill rows in co_block but kept every co_entity row. Those blobs became orphans that no later purge removed. - SQLite: copy only the co_entity rows that a retained kill row still references. This also drops orphans left by earlier purges. - MySQL/DuckDB: delete the co_entity rows of the kill rows a world purge removes, before co_block is purged. MySQL uses a join so MariaDB and MySQL 5.7 do not run a dependent subquery. Global purges keep the cheaper time-based delete, which is equivalent. If MySQL stops between the two deletes, running the same purge again removes the remaining kill rows. Player kills use the kill action with type 0 and a user id in data, so they are never treated as co_entity references. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
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 <[email protected]> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
/co purge rejects a numeric radius, but the check only saw the radius when the sender had a location. From the console, /co purge t:30d r:50 parsed no radius and no world, so it ran as a server-wide purge. The radius is now also parsed against a placeholder location, so it is rejected for every sender. r:#world is unaffected. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
MySQL deletes in place, so co_entity rows orphaned by earlier world purges stay until something removes them. With #optimize, delete every co_entity row that no kill row references, through a temporary table of referenced ids (avoids an anti-join on the unindexed co_block.data), then let OPTIMIZE reclaim the space. Failures are reported like the table loop, so the entity_spawn link cleanup still runs. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
PurgeFilter now builds the purge condition for every table, and the SQLite copy, the SQLite recovery path and the MySQL/DuckDB delete all use it instead of three hand-built copies. Behavior is unchanged; the block restriction check that the previous commit added to the SQLite copy is part of the shared condition. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
/co purge rejected entity types and actions, so mob farm kill logs could only be removed together with all other data. New arguments on SQLite, MySQL and DuckDB: - a:kill purges only entity kill rows. - i:<entity> purges kills of those entity types; it can be combined with block types. - e:<entity> keeps kills of those entity types while purging the rest. Each purged kill also removes its co_entity row. a:kill with block types, entity types in both i: and e:, e: with only block types in i:, non-entity exclusions and entity filters on ClickHouse are rejected. Any a: value other than a kill alias is rejected instead of falling through to an unrestricted purge. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
/co purge rejected any numeric radius, so kills of one entity type could only be purged across a whole world. A radius is now accepted when the purge is restricted to co_block rows with i: or a:kill, for example /co purge t:30d r:50 i:zombie. r:50x10 also limits the height. The radius becomes an x/y/z range in the co_block condition. co_entity rows follow the purged kill rows, so no entity data is orphaned, and the (wid,x,z,time) index already covers the range. Other tables are left untouched, as with any restricted purge. Rejected: a radius without i: or a:kill, WorldEdit selections, radius purges on ClickHouse, and a numeric radius from the console (it has no location, as in the console radius fix merged into this branch). Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
Contributor
|
Thanks! Scoped block/entity-kill purging is useful. Before merging, please fix two validation cases:
|
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The #optimize orphan sweep snapshots the co_entity ids that kill rows reference, then deletes every row missing from the snapshot. Another installation sharing the database could commit a kill between the two statements and lose its entity data. The sweep now only deletes rows inside the purge time range. A kill always writes its co_entity row with the current time, and a purge range ends at least 24 hours ago, so a concurrent kill never matches. A world purge deletes the entity data of the purged kills and then the kill rows. On MySQL a failure or cancellation between the two left kept kill rows without their rollback data. Both deletes now run in one transaction. Co-Authored-By: Claude Opus 5.5 <[email protected]>
A SQLite purge dropped every co_entity row no kill referenced, including rows newer than the purge range, and counted them as deleted. It now only removes unreferenced rows inside the range, like the MySQL #optimize sweep. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
/co purge t:30d e: passed validation, parsed to no exclusions, and ran as an unrestricted time purge. e:, and e:,,, did the same, as did an e: at the end of the command and an empty i:. The argument check now follows each include or exclude list across its continuation tokens and rejects a list that ends without a value. Space-separated lists such as e:zombie, villager still work. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Bukkit resolves a legacy name such as zombie_pigman to the renamed type, so the filter only matched the id of the new name. e:zombie_pigman then purged the old kills it was meant to keep, and i:zombie_pigman missed them. The filter now covers every entity map id that resolves to the type. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
/co purge t:30d r:50 r:#world_nether i:zombie ignored the explicit world and purged around the player in their current world. Two r: arguments always conflict, so the second one is now rejected before the purge starts, whether it is a world, #global or another radius. Co-Authored-By: Claude Opus 5.5 <[email protected]>
A radius purge accepted any value. A radius past the int range saturated, the area overflowed, and the purge reported success with nothing deleted. It now stops at max-radius like lookups and rollbacks. Co-Authored-By: Claude Opus 5.5 <[email protected]>
/co purge t:30d i:zombie, r:50 r:#world_nether passed the second-radius check: the validator took r:50 as a value of the include list, then saw r:#world_nether as the only radius. The radius and world parsers read both. A list now continues only with plain or minecraft: namespaced values, so a radius after a trailing comma is counted and the second one is rejected. This is the same change as 39deec3 on entity-kill-purge-filters. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01LFQuzYmYun57wJi2a5mqkM
This was referenced Oct 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR depends on PR 5. Upstream rejects any numeric radius in
/co purge, so kills of one entity type can only be purged across a whole world today. This PR accepts a radius when the purge is already limited toco_blockrows withi:ora:kill, for example/co purge t:30d r:50 i:zombie.r:50x10also limits the height.co_blockcondition.co_entityrows are purged through the kill rows they belong to, so no entity data is orphaned. The existing(wid,x,z,time)index covers the range, so no schema change is needed.i:ora:killis still rejected, because upstream appears to reject world-wide radius purges on purpose.PR 6 also depends on PR 1b and contains its commit. PR 6 replaces the blanket radius rejection, so it keeps its own check that rejects a numeric radius from the console.
Tests (local, not committed): with kills at several coordinates, a 50-block radius deletes only the zombie kills inside it and their entity data. A radius centered 1000 blocks away deletes nothing, and a height limit above the kills deletes nothing.
a:killwith a radius deletes every kill inside it. The tests passed on SQLite, DuckDB and MySQL 8. With the radius bounds removed, all five radius tests fail.