Missing detailed error description when label could not be created

[HenKun]

We couldn't create a label and got the error:

Versandetikett konnte nicht erstellt werden: Keyword validation failed: Data must match exactly one schema, but matched none. Value: "{"name1":"Anonymized","addressStreet":"Anonymized","postalCode":"12345 ","city":"Anonymized","country":"DEU","addressHouse":"3"}". Path: "shipments[0]"

The error tells nothing about the reason. The real reason is hidden in League\OpenAPIValidation\Schema\Exception\NotEnoughValidSchemas::$innerExceptions.

But this property is swallowed and is not evaluated or shown to the user. The $innerExceptions contains the errors why the four different schemas ContactAddress, Locker, PostOffice and POBox failed.

In our case, those four errors were:

Keyword validation failed: Data does not match pattern '#^[0-9A-Za-z]+([ -]?[0-9A-Za-z]+)*$#u'
Keyword validation failed: Required property 'lockerID' must be present in the object
Keyword validation failed: Required property 'name' must be present in the object
Keyword validation failed: Required property 'poBoxID' must be present in the object

Since it was a contact address, the pattern #^[0-9A-Za-z]+([ -]?[0-9A-Za-z]+)*$#u did not match. While not visible at the first glance, this means the postal code could not be validated. In our case the postal code contained a trailing space, leading to the failed generation of the shipping label. The trailing space was not visible in the GUI.

So it would be nice if the real reason, the innerExceptions would be presented to the user, so he immediately sees, why the label could not be generated.

[mam08ixo]

Hi @HenKun, thank you for your request.

The schema validator messages are very technical and, during development, we decided against presenting them to the end user. In your example, I consider it more helpful to have the invalid address part presented than to see the inner messages. You figured out what they mean, but I would argue that this takes some level of expertise beyond using the application.

We may collect more examples where the full output turns out useful. For now, I would rather not change it.

[mam08ixo]

An alternative idea would be to disable schema validation when connecting to the production endpoint. The error messages from the web service are a lot more user-friendly than the client-side schema errors.

[HenKun]

In other cases the error might be more obvious, so the inner exceptions might not be needed. But for the trailing space I needed to dive deeper, since I simply did not see it. Just if you get an idea it might be improved in some way or another. For now I know what to be aware of and where to check. That won't happen that often.

[mam08ixo]

Hi @HenKun, execute composer update --with-dependencies dhl/shipping-m2 to install version 2.1.0 of the API SDK. Schema validation is now only applied in sandbox mode. In production mode, the web service performs the validation, resulting in more user-friendly error messages in the UI.