Skip to content

Conversation

@chickeneer
Copy link
Contributor

@chickeneer chickeneer commented Dec 29, 2025

Related Mojira issue created (reproduced separately): https://report.bugs.mojang.com/servicedesk/customer/portal/2/MC-305352

Running a paper server. An item dropped on the ground from before 1.13 (so say 1.12.2). When loaded the following error is logged into the console.

[Server thread/WARN]: [ca.spottedleaf.moonrise.paper.PaperHooks] [ca.spottedleaf.moonrise.paper.PaperHooks] Serialization errors:
chunk@[-1488, 1166]:
  [1]: Failed to decode value '"ellisbrewer"' from field 'Thrower': Not a list

Item entities used to store the Thrower as a player name. Then on the 1.12 -> 1.13 update, they started storing as UUID L/M version. Though, searching the code, I cannot find a datafixer that dropped the old data.
https://minecraft.wiki/w/Java_Edition_1.13#:~:text=in%20each%20compound.-,thrower,-and

Then in the 1.15.2 -> 1.16 update. They convert the UUID L/M to the array of 4 Ints. (Data converter 2514)
https://minecraft.wiki/w/Java_Edition_1.16#:~:text=now%20much%20darker.-,uuids,-UUIDs%20stored%20in

Hence the issue of being Not a List. By my best figuring. The issue is that the EntityUUIDFix/V2514 is passing on the original name String, instead of removing it completely when it can't convert it to a modern UUID.

The solution proposed is to always remove the old data, regardless of whether a not null uuid was found. Reason it isn't already, is probably due to that data being lost. But the consequence is this error...

@Spottedleaf
Copy link
Member

This looks correct to me, although I do want to wait a bit and see how Mojang responds.

@chickeneer
Copy link
Contributor Author

Noting that the Mojang issue was closed as "Won't Fix".
https://report.bugs.mojang.com/servicedesk/customer/portal/2/MC-305352

There was no further commentary on it. My take, is that non-essential conversion errors that 'just' result in one-time console spam is not considered worth dev time for such old versions. And I don't necessarily blame them for that perspective (if that is it).

The other possibility, is the desire to "keep" that invalid data around as long as possible, since they or 3rd parties that want to inject and save that data to a different location, instead of just throwing it away. Why change it to be discarded, when someone might want the data to stick around. (But it is getting discarded right now anyway...)

I am running the patch on our server and it tested fine when recreating the issue. Doesn't matter to me one way or the other whether this PR is merged. The only difference is no console errors; no data integrity is necessarily improved.

@chickeneer
Copy link
Contributor Author

chickeneer commented Jan 11, 2026

Noting the following as a follow-up. This Pull Request does have one flaw.

The error will still occur if a chunk was loaded after the DataVersion 2514, but loaded on a version before the codecs that make this error so strict.

[16:32:29] [Server thread/WARN]: [ca.spottedleaf.moonrise.paper.PaperHooks] [ca.spottedleaf.moonrise.paper.PaperHooks] Serialization errors:
chunk@[-1282, 1142][0]: Failed to decode value "ellisbrewer" from field 'Thrower': Not a list

(the same error as before). When loading up that chunk before the latest loading, it shows to have been loaded in Minecraft version 1.19.2 (Data Version 3120).

So the "Proper" fix of cleaning up this data - is actually to remove this non-list of integers in a NEW or more new datafixer. Not necessarily the original fixer that messed things up.

As of right now, I am satisfied enough with the current state of my change. Acknowledging it does have a flaw...

Advise if anything in particular is desired on this.

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