You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 290cf3b
Browse filesBrowse the repository at this point in the historyBrowse files
#228 - Only delete the uploaded files written for the execution, keep them while a failed message will be retried, delete them on a rejected HTTP request
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,9 @@
1
1
Latest
2
2
------
3
3
4
+
## Fixes
5
+
*[#228](https://github.com/cleverage/ui-process-bundle/issues/228)`ProcessExecuteHandler`, `ProcessExecuteController` (`cleverage_ui_process_http_execute`): only the files written by the launch form or the HTTP API for the execution are deleted (#209), flagged by the new `deleteInput` argument of `ProcessExecuteMessage` (`false` by default): a file of the upload directory given by its path (HTTP API, text input of the launch form, schedule, default input) is no longer deleted. A message failing in a Messenger worker keeps its file while it will be retried or when it is sent to a failure transport (`messenger:failed:retry`), new internal `UploadedFileSubscriber`. The file uploaded with a request rejected by the HTTP API (422) is deleted. The messages queued by 3.4 have no flag: their file is no longer deleted by the worker, it may need a manual cleanup of the upload directory (`cleverage_ui_process.upload_directory`). Update documentation, add tests.
| `cleverage_ui_process.upload_directory` | `%kernel.project_dir%/var/storage/uploads` | Directory where files uploaded from the launch form or the [HTTP API](06-http_api.md) are stored before being passed as process input. |
100
-
| `cleverage_ui_process.delete_uploaded_files` | `true` | Delete the uploaded file once the process has been executed (successfully or not), by the Messenger handler or by the HTTP API when the process is not queued. Only the files of `cleverage_ui_process.upload_directory` are deleted. Set it to `false` to keep them, e.g. when a process stores the path of its input. |
100
+
| `cleverage_ui_process.delete_uploaded_files` | `true` | Delete the uploaded file once the process has been executed (successfully or not), by the Messenger handler or by the HTTP API when the process is not queued; the file of a request rejected by the HTTP API is also deleted. Only the files written by the bundle for the execution are deleted, never a file given by its path, even in `cleverage_ui_process.upload_directory`. A message failing in a Messenger worker keeps its file while it will be retried, or when it is sent to a failure transport (see [messenger](08-messenger.md#uploaded-files)). Set it to `false` to keep them, e.g. when a process stores the path of its input. |
101
101
| `upload_directory` | `%cleverage_ui_process.upload_directory%` | Deprecated since 3.3, removed in 4.0: use `cleverage_ui_process.upload_directory`. When your application still sets it, its value is used, with a deprecation. If your application has its own `upload_directory` parameter (e.g. for another bundle), also set `cleverage_ui_process.upload_directory`: the bundle then leaves `upload_directory` alone, without deprecation. |
|`code`|`string`|**X**|| Code of the process. It must exist and be public. |
34
-
|`input`|`string` or file ||`null`| Process input. With form data, it can be an uploaded file: the file is saved in the `cleverage_ui_process.upload_directory` directory (see [bundle configuration](01-bundle_configuration.md#container-parameters)) and its path is passed as input; the file is deleted once the process has been executed, unless `cleverage_ui_process.delete_uploaded_files` is `false`. |
34
+
|`input`|`string` or file ||`null`| Process input. With form data, it can be an uploaded file: the file is saved in the `cleverage_ui_process.upload_directory` directory (see [bundle configuration](01-bundle_configuration.md#container-parameters)) and its path is passed as input; the file is deleted once the process has been executed, or when the request is rejected (422), unless `cleverage_ui_process.delete_uploaded_files` is `false`. A file given by its path is never deleted. |
35
35
|`context`|`object` or JSON `string`||`{}`| Process context, as key/value pairs. A JSON string must decode to an object or an array (`422` otherwise). With form data, send one field per value: `context[key]=value`. |
36
36
|`queue`|`bool`||`true`|`true`: the process is queued to the `execute_process` transport (see [messenger](08-messenger.md)). `false`: the process is executed during the HTTP request. |
|`CleverAge\UiProcessBundle\Message\ProcessExecuteMessage` (`code`, `input`, `context`) |`execute_process`| Executes the process with the process manager, like `cleverage:process:execute`. |
13
+
|`CleverAge\UiProcessBundle\Message\ProcessExecuteMessage` (`code`, `input`, `context`, `deleteInput`) |`execute_process`| Executes the process with the process manager, like `cleverage:process:execute`. |
14
14
|`CleverAge\UiProcessBundle\Message\CronProcessMessage` (`processSchedule`) |`scheduler_cron`| Reads the schedule again, and dispatches a `ProcessExecuteMessage` with its current input and context, unless it has been disabled or deleted. |
15
15
16
16
You can dispatch a `ProcessExecuteMessage` yourself to queue a process from your code:
@@ -27,6 +27,22 @@ public function importProducts(string $filePath): void
27
27
}
28
28
```
29
29
30
+
Uploaded files
31
+
--------------
32
+
33
+
The launch form and the HTTP API set `deleteInput` (`false` by default) when the input is the file they have just
34
+
written in the upload directory: the file is deleted once the process has been executed, successfully or not (see the
35
+
`cleverage_ui_process.delete_uploaded_files`[parameter](01-bundle_configuration.md#container-parameters)). In a
36
+
worker, the file of a failed message is kept while the message will be retried (retry strategy of the transport), or
37
+
when it is sent to a failure transport, so that `messenger:failed:retry` executes it with its file. It is deleted once
38
+
the message no longer fails, or when it fails again from the failure transport and Symfony drops it (not sent again to
39
+
the failure transport it has been received from). A file of a message removed from the failure transport
40
+
(`messenger:failed:remove`) is kept. With Symfony 6.4.0 to 6.4.4, which sends a message failing again from the failure
41
+
transport back to it, its file is deleted anyway.
42
+
43
+
The messages queued by the version 3.4 of the bundle have no `deleteInput`: their file is not deleted, you may have to
0 commit comments