[oskardudycz]

If your message is a class instead of a record, adding a required field didn't fail the compatibility check. Now it does.

Plus: failure messages now say which field or value broke, instead of just "Deserialization as X failed".

Compatibility checks apply two rules:

• shared fields must match,
• fields the reader requires must be present in the data. Messages modelled as a class only ran the first.

So for the stored event in JSON:

{ "orderId": "00000000-0000-0000-0000-000000000001" }

And reader class:

public final class OrderPlaced {
    public final UUID orderId;
    public final String currency;

    @JsonCreator
    OrderPlaced(@JsonProperty("orderId") UUID orderId, @JsonProperty("currency") String currency) { ... }
}

thenBackwardCompatible() check passed, leaving currency null. It now fails with: Required field 'currency' in OrderPlaced is null after deserialization.

Failure messages were also identical for every cause. A strict reader meeting an unknown field and a reader meeting an unknown enum value both reported Deserialization as OrderPlaced failed. The message now carries the cause, so it names missing properties.

Internal assertion assertRequiredFieldsSatisfied used for those checks returned early for anything that wasn't a record, so a class that added a required field passed.