A bunch of API actions are designed to be performed by the controller code in synchronous mode, that is, they block until the operation finishes (successfully or not). This means the puma process associated with the controller action is blocked and unavailable from the pool of HTTP servers during that tijme.
Once such action is the 'register' action in the DataProvider controller. Not only does it block it also wrongly rename its process name while doing so (that is because in non API mode, it does fork in background, and in that case renaming the process is a useful feature for the sysadmin).
We should go through the entire set of API requests and for any of them that take a significant amount of time, make it always go in background, and provide a way for the API client to query the state of the operation.
A bunch of API actions are designed to be performed by the controller code in synchronous mode, that is, they block until the operation finishes (successfully or not). This means the puma process associated with the controller action is blocked and unavailable from the pool of HTTP servers during that tijme.
Once such action is the 'register' action in the DataProvider controller. Not only does it block it also wrongly rename its process name while doing so (that is because in non API mode, it does fork in background, and in that case renaming the process is a useful feature for the sysadmin).
We should go through the entire set of API requests and for any of them that take a significant amount of time, make it always go in background, and provide a way for the API client to query the state of the operation.