Currently long running commands started via the HTTP API would time out and the user can possibly not determine if the command just took too long for the network time-out or something server-side went wrong. So if the user is aware that a command will take long they should be able to mark such a command so the server returns an Accepted HTTP status (202) and executes the command without reporting its result.
The proposed parameter for the POST request body is awaitResponse which is by default true.
For example (using an example from the docs):
curl -X POST http://localhost:2480/api/v1/command/school \
-d '{ "language": "sql", "command": "create document type Class", "awaitResponse":false}' \
-H "Content-Type: application/json" \
--user root:arcadedb-password
Would just return status 202. If the command worked has to be checked in the log.
Note: As discussed with @lvca on Discord.
Currently long running commands started via the HTTP API would time out and the user can possibly not determine if the command just took too long for the network time-out or something server-side went wrong. So if the user is aware that a command will take long they should be able to mark such a command so the server returns an
AcceptedHTTP status (202) and executes the command without reporting its result.The proposed parameter for the POST request body is
awaitResponsewhich is by defaulttrue.For example (using an example from the docs):
Would just return status
202. If the command worked has to be checked in the log.Note: As discussed with @lvca on Discord.