Skip to content

#174 - Reset the process execution state between two messages of a worker - #178

Merged
njoubert-cleverage merged 1 commit into
mainfrom
174
Oct 16, 2026
Merged

njoubert-cleverage merged 1 commit into
mainfrom
174

Conversation

@njoubert-cleverage

Copy link
Copy Markdown
Member

Description

Fixes #174.

  • ProcessExecutionManager implements ResetInterface (kernel.reset tag): the current and last process executions are set to null between two messages of a long-running worker (Messenger execute_process transport, scheduler). When the end of an execution failed before unsetProcessExecution(), the execution stayed the current one, and the next process executed by the worker was attached to it (setCurrentProcessExecution() keeps the current one): status, report, logs in database, stop requests.
  • DoctrineProcessHandler::reset() (kernel.reset tag) drops the log records not written at the end of the previous execution (failed flush), which would be attached to the next one.
  • ProcessEventSubscriber::success() / fail(): the ended execution is unset, and its log file closed, even when save() fails (try / finally). The error is still thrown; the ProcessExecutionEndedEvent is not dispatched in this case (as before).

ProcessHandler (log file) was already reset by Monolog: StreamHandler::reset() closes the file (close() unsets the file name), called by Logger::reset() (kernel.reset tag of the loggers). Same approach as cleverage/process-bundle#301 for ProcessManager.

Checked in process-bundle-demo (patch applied to the vendor):

  • debug:container --tag=kernel.reset: cleverage_ui_process.manager.process_execution and cleverage_ui_process.monolog_handler.doctrine_process (reset), with cleverage_process.manager.process;
  • messenger:consume execute_process on a successful execution then a failed one (unknown process): two executions with their own status, log file and log records.

The failed save scenario is covered by the unit tests (not reproducible in the demo without breaking the database).

Tests: ProcessExecutionManager::reset(), DoctrineProcessHandler::reset(), end of an execution whose save fails (success and fail), kernel.reset tags. With coverage (pcov): no risky test, no new uncovered line.

Requirements

  • Documentation updates
    • Reference
    • Cookbooks
    • Changelog
  • Unit tests

Breaking changes

None: new reset() methods; the end of an execution behaves the same when its save succeeds.

🤖 Generated with Claude Code

…rker

- ProcessExecutionManager implements ResetInterface (kernel.reset tag):
  current and last process executions set to null. When the end of an
  execution failed before unsetProcessExecution(), the execution stayed the
  current one in the worker, and the next process was attached to it
  (setCurrentProcessExecution() keeps the current one).
- DoctrineProcessHandler::reset() (kernel.reset tag) drops the records not
  written at the end of the previous execution (failed flush).
- ProcessEventSubscriber: the ended execution is unset, and its log file
  closed, even when save() fails (try / finally); the error is still
  thrown, the ended event is not dispatched.

ProcessHandler was already reset by Monolog (StreamHandler::reset() closes
the file, Logger::reset() on kernel.reset).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
@njoubert-cleverage
njoubert-cleverage merged commit f9fcc74 into main Oct 16, 2026
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ProcessExecutionManager is not reset between two messages of a worker

1 participant