Closed arnoweiss closed 1 year ago
As you already suspected, the reason for the exception is that the serialization fails because of the duplicate idShort which makes the AAS model invalid. Unfortunately, the currently is no check for uniqueness of identifiers- A similar issue has already been raised previously (see https://github.com/FraunhoferIOSB/FAAAST-Service/issues/326).
We have this in our backlog but are still hoping that validation like this will be part of aas4j. However, currently it does not seem like proper validation will be available in aa4j in the near future so we might rethink implementing this ourselves.
Another thing I noticed during debugging your example is that currently FA³ST support model validation only for the initial loading of a model but does not apply this when the model is updated via the API. This is definitely something that will go into our backlog.
Unfortunately, this means that your problem will currently remain as-is as adding this kind of validation will probably not be our top priority right now because it "only" happens when the model is invalid in the first place. For this reason I'm also changing the label from bug
to enhancement
but will keep the issue open.
I managed to address this issue quicker than anticipated and already published an update on validation with https://github.com/FraunhoferIOSB/FAAAST-Service/commit/9520c84f39fe5eea007a19b98f8b04b8f2711dc4
FA³ST Service now supports validation not only on loading the initial model at startup but also when creating or updating elements via the API. Additionally, new validation checks for uniqueness of idShort and identifiers have been added together with the capability to configure which validation is performed at which step in detail (see documentation https://faaast-service.readthedocs.io/en/latest/gettingstarted/configuration/).
Please close the issue if this solves your problem and if not please provide details what is missing or not working properly.
Thanks, this works in the sense that I'm getting a more expressive error message now with all relevant validation errors. However, a failed validation is no HTTP 500 as I understand it - after all, the server is acting as expected. Shouldn't it rather be deemed a bad request?
If you want, I can close this ticket and open a separate one since the new feature is functional.
Yes, you are right, HTTP 500 seems not appropriate here. better suited would be 400 Bad Request
or even 422 Unprocessable Entity
meaning "The request was well-formed but was unable to be followed due to semantic errors".
Any preferences from your side which code to return?
No strong preference. I've never seen 422 in the wild so 400 with the validation errors attached should suffice. Feel free to close this ticket when either is implemented.
FA³ST Service now correctly returns 400 Bad Request
when a request to create/update an element is made with invalid content. Details about the validation errors are provided in the response body.
Describe the bug Value-only serialization fails for a given Submodel. To Reproduce
GET {{baseUrl}}/submodels/dXJuOnV1aWQ6OWQ2YzFmMDMtM2YzZS0zZDMwLWEzM2QtMDg5NWI1ZjE3NmE3/submodel?content=value
Expected behavior
Output
Additional context I suspect that this is because the Submodel is invalid itself. Thevalue-only-serialization would produce invalid json due to the twice-bound key "ChildData". Is there any way to verify this?