## Problem / motivation `Drupal\flowdrop_session\Service\SessionService::sendMessage()` does two unrelated things in one call: it **appends a user message to the session's room**, and it **launches a workflow pipeline** for that message. Conflating the two means callers cannot post a message without triggering execution, and cannot launch a pipeline from an existing message. It also couples the session service to the executor, which now owns launching behind a BC-locked interface. The responsibilities have since been split into two focused APIs: - `SessionService::postMessage()` — append a message to the room only. - `WorkflowLauncherInterface::launch()` (HTTP: `POST /run`) — start a pipeline for a workflow, with validated, named inputs. ## Deprecated `SessionService::sendMessage()` is deprecated and will be removed. Callers should post the message and launch the pipeline as two explicit steps. ## Before ```php $message = $sessionService->sendMessage($session, $content, $inputs); After // 1. Append the user's message to the room. $message = $sessionService->postMessage($session, $content); // 2. Launch the workflow pipeline for the session. $result = $workflowLauncher->launch( $session->getWorkflow(), $inputs, new LaunchOptions(sessionId: $session->id()), ); ``` The workflow launcher resolves named inputs against the workflow's declared input ports, validates them, and dispatches via the workflow author's declared orchestrator (async queue worker or in-process deferred execution). The caller no longer controls the dispatch path. Remaining work The FlowDrop playground (flowdrop_playground) is the last in-tree consumer of sendMessage(). The deprecation call site there is suppressed with a scoped @phpstan-ignore method.deprecated until the playground is migrated to the post + launch flow, after which the method is removed. > Change record: [#3593549](https://www.drupal.org/node/3593549)