## Problem When a node fails with an exception whose **message itself cannot be stored**, the runtime's failure recording fails too, and nothing falls back. The pipeline and the job keep `status = running` forever, `launch(wait: TRUE)` returns `running` to the caller, and no error is recorded anywhere except watchdog. Trigger seen in the wild (filed separately as #3592446): `TextOutput` byte-truncates a string inside a multibyte character, the session message INSERT is rejected with MySQL error 1366, and Drupal's `ExceptionHandler` puts `print_r($arguments)` — including the invalid bytes — into the `DatabaseExceptionWrapper` message. From then on every `markAsFailed($e->getMessage())` save hits the same 1366 error on `error_message`. Any exception message with bytes a `utf8mb4` column refuses (invalid UTF-8, a stray surrogate) reproduces it. Exception messages that echo user or model content are the normal case for node failures, so this is not exotic. ## Observed sequence flowdrop-ai-bench runner, `2.x` at `771e7c77`, Drupal 11.4.6, MariaDB 10.11, PHP 8.4, drush `bench:run` → `WorkflowLauncher::launch(..., new LaunchOptions(wait: TRUE))`, parent workflow `bench_5_react_agent` (synchronous orchestrator) whose only node is a `flowdrop_workflow_react_agent_with_tools` sub-workflow node. Parent pipeline 434, child 435; identical traces for 672/673 and 675/676. Watchdog, all within the same second: 1. `flowdrop_stategraph`: child StateGraph `completed` in 24.3 s, 15 jobs. Child pipeline 435 is saved `completed`. 2. `flowdrop_pipeline` (error): `SqlContentEntityStorage->doSaveFieldItems()` — INSERT of the session's assistant message fails, 1366 on `flowdrop_session_message.content`. 3. `flowdrop_session` (warning): "Pipeline cleanup failed after orchestration error" — `SessionExecutionService.php:387-393` calls `$pipeline->markAsFailed($e->getMessage())` + save, which fails with 1366 on `flowdrop_pipeline.error_message`, and the warning is the end of it. 4. `flowdrop_runtime`: "Node flowdrop_workflow_react_agent_with_tools.1 executed successfully in 24.397 seconds" — logged even though `WorkflowNode::process()` then throws `Sub-workflow react_agent_with_tools failed: SQLSTATE[22007] …`. 5. `flowdrop_job` (error): `AbstractOrchestratorBase::executeJob()` catch → `$job->markAsFailed($e->getMessage()); $this->jobStorage->save($job);` (`AbstractOrchestratorBase.php:316-317`) — save fails, 1366 on `flowdrop_job.error_message`. The `\Exception` is rethrown from inside the catch, so `dispatchJobCompleted` and the error log after it never run. 6. `flowdrop_pipeline` (error): `SynchronousOrchestrator` catch → `$pipeline->markAsFailed($e->getMessage()); $this->getPipelineStorage()->save($pipeline);` (`SynchronousOrchestrator.php:653-654`) — fails the same way. 7. `flowdrop_workflow_executor` (error): `DeferredPipelineProcessor.php:151` "Execution failed for pipeline 434: SQLSTATE[22007] … (EntityStorageException)". 8. `flowdrop_workflow_executor`: "Launched workflow bench_5_react_agent as pipeline 434 (… waited: true)". The `LaunchResult` status is `running`. End state, unchanged hours later: pipeline 434 `running`, job 4098 (`flowdrop_workflow_react_agent_with_tools`) `running` with `started` set and `completed` NULL, job 4097 (`chat_output`) `idle`, child pipeline 435 `completed`, no session assistant message, no `error_message` anywhere. `recoverStuckSessions()` cannot help: the parent run has no session, and the pipeline row looks like a live run. ## Why this is a runtime bug 1. **Failure recording is not fail-safe.** `markAsFailed()` + save is the only way a pipeline or job leaves `running` on the error path, and it is attempted once with the raw exception message. If that save throws, the status change is lost with it. The status transition matters more than the message text. 2. **The parent job's failure is invisible.** Because the catch in `executeJob()` rethrows after a failed save, the caller gets an exception but the job row never records it, and the "executed successfully" info line (step 4) is the last thing logged about the node. 3. **`launch(wait: TRUE)` reports `running` for a run that will never progress.** The DTO promises "the FINAL pipeline status instead of PENDING"; `running` is not a final status, and a synchronous run that has returned cannot still be running. Callers (drush, cron, tests) cannot distinguish this from a genuinely in-flight async run. ## Proposed fix 1. **Sanitize before persisting.** In `FlowDropPipeline::markAsFailed()` and `FlowDropJob::markAsFailed()` (or a shared helper the orchestrators call), make the stored message valid UTF-8 and bounded: `mb_convert_encoding($m, 'UTF-8', 'UTF-8')` or `Unicode::validateUtf8()` with a fallback, then `mb_strcut()` to a sane cap (`error_message` is `longtext`; a few KB is plenty, the full text stays in watchdog). Strip the `print_r` argument dump from `DatabaseExceptionWrapper` messages, or keep only the first line, since it echoes the very data that failed. 2. **Make the status transition survive a failed save.** In the `executeJob()` and `SynchronousOrchestrator` catch blocks, wrap the `markAsFailed` save in its own try; on failure, retry once with a generic message (`"Node failed; the error text could not be stored, see watchdog"`) so the row leaves `running`. Same in `SessionExecutionService.php:387`. 3. **`launch(wait: TRUE)` must not return `running`.** After the inline run, if the pipeline is still `running`/`pending`, treat it as failed (mark it, if step 2 did not already) and return `failed` with the last error, so `bench:run`, cron and tests see the truth. 4. A kernel test: a node processor whose exception message contains `"\xE2..."` (invalid UTF-8) under the synchronous orchestrator → pipeline and job end `failed`, `error_message` is valid UTF-8, `launch(wait: TRUE)` returns `failed`. Related: #3592445 (a bookkeeping save failure classified as a node failure) is the neighbouring weakness in the same catch blocks; #3592441 covers stuck-session recovery, which does not reach a session-less parent pipeline like this one.