With the query I gave as an example, I see 2 possible ways to get the result.
Direct query response (if status is Complete)
As a notification (if status is Processing) and use the downloadUrl
I was wondering if it was documented anywhere what is the threshold for these 2 types of responses. I can see that for testing purposes, we can force it to be async and/or force to have a download link. How can you refrain someone from forcing false to both of these parameters in a production application? Or the other way around, how can you refrain someone from forcing the download url in order to implement only one of the 2 ways in a custom application and bypassing the notification?
Can we have a guarantee to implement only one of the 2 ways depending on the number of agents in the management unit?
I was wondering if it was documented anywhere what is the threshold for these 2 types of responses.
We don't document the exact threshold for when something will go async because we need the flexibility to adjust those thresholds. That is why we exposed the force flags, so that both our internal developers and external developers can thoroughly test their client applications to ensure that they can seamlessly handle the response, regardless of whether it comes synchronously via the api or asynchronously via notification.
How can you refrain someone from forcing false to both of these parameters in a production application? Or the other way around, how can you refrain someone from forcing the download url in order to implement only one of the 2 ways in a custom application and bypassing the notification?
It is not possible to set the value to false. If you pass "false" then we simply ignore the parameter. You can force it to go async or to go to download service, but you can't force it to go sync or not to go to download service if our backend deems it necessary. The idea is to allow clients to test the asynchronous aspect of their applications.
If a client sets it to false, it's the same as if they didn't pass the parameter at all. If someone wants to write their application to always go async, that doesn't really bother us any as it doesn't put any additional load on the back end. It would add unnecessary delays in receiving the normally synchronous responses on the client side, but if the client is willing to live with that then that's fine.
Can we have a guarantee to implement only one of the 2 ways depending on the number of agents in the management unit?
No. The default way of determining whether to send a response asynchronously depends on how long the request is taking to process. When it hits a certain threshold the back end will make the determination to switch to an asynchronous response. While unlikely, it is possible that a management unit with a single agent could go async during periods of high load. As for forcing download, that depends on the total size of the response and whether it can be safely passed through on the response body.
If you want to always process the response in the same way, the option to always force async/force download is available, though we would recommend handling both cases as your client application will be more performant if you do.