Compat issue between adventure lib and message-api

[suerion]

Hey, i had an issue on WorldGameRule on executing an Command,

I had added there an Issue and the dev said, i should add here also an issue, because there is an issue with Better-Fabric-Console and the Libs.

You could find the issue and the Console log there

https://github.com/DrexHD/WorldGameRules/issues/2

There is also the latest.log

[kezz]

I'm not sure what we would do to fix this. It looks to me more like this message plugin is creating malformed components which we're not going to do anything about.

[suerion]

If i could help, say something, i could test on my dev enviroment. DrexHD has send me here @DrexHD

[DrexHD]

I'm not sure what we would do to fix this. It looks to me more like this message plugin is creating malformed components which we're not going to do anything about.

I didn't look into this issue yet, but for context, this is likely not a malformed component. message-api adds a new component type that is only present server side and converted into vanilla types during serialization.

[kezz]

I'd like @zml2008 or @jpenilla to confirm, but I don't believe we would want to support custom ComponentContents implementations.

[DrexHD]

I wouldn't really expect support for serialization of the custom Component, but I am a bit confused why the adventure lib is involved in this case anyways (when sending vanilla components to a command source).

[jpenilla]

I'm not sure what we would do to fix this. It looks to me more like this message plugin is creating malformed components which we're not going to do anything about.

I didn't look into this issue yet, but for context, this is likely not a malformed component. message-api adds a new component type that is only present server side and converted into vanilla types during serialization.

The issue here appears to be that you are not always converting to vanilla during serialization: https://github.com/DrexHD/message-api/blob/7392b80d6f90a5f82a2916fc212d0b7e0942e9da/src/main/java/me/drex/message/mixin/ComponentSerializationMixin.java#L50 So we end up with an invalid serialized form that can't be deserialized. In this case, breaking the conversions needed by better fabric console for it's logging improvements, but this would also break anything else trying to deserialize the component. I don't think this is an adventure issue or even something we could reasonably resolve on our end.

[DrexHD]

It is only parsed to vanilla components when the context is network serialization for a player. I have also added the codec for serialization of my custom component to the vanilla component codec, so this doesn't cause any issues in vanilla, when it is (de)serialized eg. in an item name!

[jpenilla]

In a modded context it's not reasonable to assume that (outside of sending to a client) a serialized component will only ever be attempted to be deserialized by the same game instance using vanilla logic. Any mod serializing a component should be able to safely assume the format is valid and readable by any spec-compliant deserializer. Changing the serialized format breaks this.

At first glance, I think you could partially fix this by always converting to vanilla, except during item component serialization or other areas you need to round-trip your custom component. Of course, this would still lead to invalid serialized forms floating around, but it's less likely to cause problems that way. But, regardless of if that works, this just isn't something we can resolve on our end or consider an adventure issue.