0ed4f05d63
When using the command `mistral run-action`, by default it will run the action synchronously unless the action can only be used asynchronously (action.is_sync returns False). When it runs synchronously the result of the action is not saved. When it is ran asynchronously the result is saved, as you need to retrieve it from Mistral afterwards. There is a argument on the command `--save-result` that can be used, it causes the action to be ran asynchronously and the result is saved. There is no way to have the action run synchronously and have the result be saved. This patch adds a new API parameter `run_sync` which will be exposed by the CLI as `--run-sync`. This new argument is intended to be used with `--save- result` but can be be used independently to ensure an action isn't ran synchronously by mistake. With the new argument the behaviour of the command is now as follows: * `mistral run-action` This behaves as it did before, it runs synchronously if it can, or it schedules for later and saves the action. * `mistral run-action --save-result` Again, this is the same as before, it schedules the action to run later and the action is saved. * `mistral run-action --run-sync` This is similar to having no argument passed, however, if you try to run an action that can't be used synchronously it will be rejected and an error is returned. * `mistral run-action --run-sync --save-result` The combination of the two arguments runs the actions synchronously and saves the result. If the action can't be ran synchronously then an error is returned. (This commit message uses the CLI to demonstrate the API usage, the new argument is added in in a mistralclient patch. It can of course be used directly via the API also.) Change-Id: I4417750fd5ff47016357655370410e9e7348cc25 |
||
---|---|---|
.. | ||
controllers | ||
hooks | ||
__init__.py | ||
access_control.py | ||
app.py | ||
service.py | ||
wsgi.py |