Skip to content

Don't fail component parsing on unparseable hex colors - #3029

Merged
octylFractal merged 2 commits into
EngineHub:version/7.4.xfrom
fbrandt-dev:fix/hex-color-drop
Oct 2, 2026
Merged

octylFractal merged 2 commits into
EngineHub:version/7.4.xfrom
fbrandt-dev:fix/hex-color-drop

Conversation

@fbrandt-dev

Copy link
Copy Markdown
Contributor

Vanilla text components may carry hex colors (#RRGGBB) since 1.16, which text3 cannot represent. Deserializing such a component threw JsonParseException and failed parsing the whole component (e.g. item names via getRichItemName).

This drops the unparseable color instead, keeping the text content. Named colors still parse as before.

@fbrandt-dev
fbrandt-dev requested a review from a team as a code owner October 2, 2026 17:22
Vanilla text components may carry hex colors (#RRGGBB) since 1.16, which
text3 cannot represent. The old TextColorWrapper deserialization threw
JsonParseException and the whole component parse failed.

This drops the unparseable color instead, keeping the text content.
Named colors still parse as before.
Addresses review feedback on EngineHub#3029: keep the parse-failure stacktrace
available at debug level, and add the GPL header to the new test class.

@octylFractal octylFractal left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@octylFractal
octylFractal enabled auto-merge October 2, 2026 23:06
@octylFractal
octylFractal added this pull request to the merge queue Oct 2, 2026
Merged via the queue into EngineHub:version/7.4.x with commit 1fcbef5 Oct 2, 2026
2 checks passed
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