I wanted to update this to hopefully bump the issue but also give an example of how this is going to present as a huge maintainability issue if pushed to production as-is:
Imagine that there is an enterprise-level process that would like to leverage UiPath. The current enterprise process uses API calls to push data, so it would like to use a UiPath endpoint to be able to send the data over, the obvious option would be to use the AddQueueItem endpoint that is provided by the Orchestrator out-of-the-box. Wanting to be able to give some early validation warnings synchronously (knowing that final success/failure can only be given asynchronously and could potentially take a long time depending on average transaction processing time and queue), one would expect to provide a queue schema. When the enterprise process starts sending data, they are either going to get back a 201 success code or an exception. The exception message is simply something like “Data did not meet the queue schema requirements.” This means that there are going to be questions relating to why that specific payload was not accepted by UiPath, and the UiPath developer that is tasked with figuring out is not going to have any further information to go on.
Best case scenario:
UiPath to give a full error message with the fields that exceptioned out, the values passed, and the validations that it did not pass (note that this could mean things like with If-statements with compound validations, not just field values)
Workaround 1 (Validations, but slow):
Could keep the validation schema in an asset, when the transaction is picked up to process, then it can be checked against using the json schema format.
Workaround 2 (Validations, but not as slow):
Have a separate process that listens to an input queue for the data where the queue does not have validations. This process solely does validations and either responds back to the enterprise process with a helpful validation exception or passes the work to the work queue
Workaround 3 (Rely on sanity checks):
Not as good as using the schema validation depending on the sanity checks and all validations would likely be given on a per-field basis instead of everything together. This is also harder to update if field changes are made.