Serializing Descrimination Union Not Selecting Correct Member

[justin0mcateer]

I have a schema which defines a number of different messages to be used within a protocol. There are individual schema for each message type and a union used by the protocol which includes all message types in the protocol. All of the message schema have a discriminator field (in this case 'type') which indicates the type of message, and by extension the correct/matching schema.

When parsing, this works fine. However, when serializing the wrong schema seems to be selected for the serialization and whether the correct or incorrect schema is selected seems to depend on the ordering in the union.

In the Rescript API, there appears to be a special 'tag' construct that allows specifying the discriminator. Other libraries also allow specifying the discriminator for these types of unions. It seems like it would be both more reliable and more performant to leverage an explicit discriminator when available.

[justin0mcateer]

This is the generated code on that union schema, for whatever reason, it is checking the 'collectionName' field, which is a common field, but not constant and not the discriminator.

[DZakh]

Thanks for the report. Could you share your version and the SyncResponseSchema with SyncRequestSchema code.

In the Rescript API, there appears to be a special 'tag' construct that allows specifying the discriminator.

This is the same as a literal shorthand in TS API. This needs to be a function because the ReScript lang type system doesn't allow overloads.

Other libraries also allow specifying the discriminator for these types of unions. It seems like it would be both more reliable and more performant to leverage an explicit discriminator when available.

ReScript Schema does it automatically 🙂 It Looks like, for some reason, the type field is not a literal.

[justin0mcateer]

Maybe I am holding it wrong, but I have tried everything I can think of to get this to work. I've tried S.literal, 'as const', I've tried simplifying the schema, changing the name of the discriminator field and so on. The result is always exactly the same.

Here is another interesting test, after some changes to simplify things further, serializing with the Response schema works, but serializing with the Union fails. Again, this only happens if the inputs to Union are in a particular order.

Here are the simplified schema:

As as short term work around, I am switching on the 'type' field and serializing with the schema for the specific message and that is working fine. Just creates extra code that is harder to maintain.

Also, I notice 'serialize' is marked as deprecated, but I don't see S.serializeWith exposed in the TS API.

[justin0mcateer]

As for the version, I was on 8.3.0, but I just upgraded to 8.4.0 (latest) to see if that would resolve the issue. Setting aside the API differences, the behavior in this case appears to be exactly the same between 8.3 and 8.4.

[justin0mcateer]

OK. New information. If I change the 'response' field from a Union to S.string, all the cases work correctly. So, it appears that having a discriminated Union with a field which is also a Union seems to be causing some issue. Notably, it is this field that is being left out when the object is serialized.

I checked with other non-primitive schema properties and they don't seem to trigger the problem.

[DZakh]

Super weird. I'm currently refactoring this code for V9. It's going to be more robust and performant. It's not ready yet, but I can probably cherry-pick some changes and release 8.4.1. I think it might solve the issue.

I'll keep you updated.

[DZakh]

Also, there's a chance that 8.1.0 don't have the bug, but I see that you use some later feature, so it might be difficult for you to downgrade.

[DZakh]

Yeah, I reproduced the issue. Unfortunately, the cherry-picking is not possible as I initially thought.

For now, I set 8.1.0 as the latest version on npm and have notified people on Twitter to use it until I release v9 with a fix.

https://x.com/dzakh_dev/status/1853855075061367150

[DZakh]

Published https://github.com/DZakh/rescript-schema/releases/tag/v9.0.0-rc.1 with a fix.

It still requires to write a change log and update documentation, but the code isn't going to be changed until the official v9 release.