Iván Ovejero 8cd4db0ab7 refactor(core): Simplify marking logic in binary data manager (no-changelog) (#7046) ... - For a saved execution, we write to disk binary data and metadata. These two are only ever deleted via `POST /executions/delete`. No marker file, so untouched by pruning. - For an unsaved execution, we write to disk binary data, binary data metadata, and a marker file at `/meta`. We later delete all three during pruning. - The third flow is legacy. Currently, if the execution is unsaved, we actually store it in the DB while running the workflow and immediately after the workflow is finished during the `onWorkflowPostExecute()` hook we delete that execution, so the second flow applies. But formerly, we did not store unsaved executions in the DB ("ephemeral executions") and so we needed to write a marker file at `/persistMeta` so that, if the ephemeral execution crashed after the step where binary data was stored, we had a way to later delete its associated dangling binary data via a second pruning cycle, and if the ephemeral execution succeeded, then we immediately cleaned up the marker file at `/persistMeta` during the `onWorkflowPostExecute()` hook. This creation and cleanup at `/persistMeta` is still happening, but this third flow no longer has a purpose, as we now store unsaved executions in the DB and delete them immediately after. Hence the third flow can be removed.		2023-08-31 16:02:20 +02:00
..
nodes	refactor(core): Simplify marking logic in binary data manager (no-changelog) (#7046)	2023-08-31 16:02:20 +02:00
utils	feat(editor): SQL editor overhaul (#6282)	2023-06-22 16:47:28 +02:00