A patch release built from a week of running agent
workflows three at a time against one site. Under that load the runtime kept
tripping over its own bookkeeping: two runs would deadlock on a shared cache
table, a scheduler would lose the very job it had just made ready, a failure
message the database refused would leave a run marked "running" forever, and
a loop would run a stale job from an earlier round. Each of these is fixed at
its cause, and each has a test that keeps it fixed.
A single-bug patch. If a workflow asks the person running it
for something more than once — enter a URL, then approve the request that uses
it — the second prompt arrived with no buttons and no input field.
It read only "Action required", and the run could not be answered. It sat
waiting forever.
A rule-conformance patch. Almost all of it comes from one sweep: the
specification registry's rules were read against the code that claims to
implement them, and every place the two disagreed was closed. Nothing here is a
new feature — each entry is a promise the module already made and did not keep —
but several of them change what a working workflow does, because a rule the code
was breaking is a rule someone's graph may have been leaning on. Read the
This release lets a port say what kind of thing it carries, not just
whether it is text or a list. A port can now be marked as carrying an Order, an Invoice, or a chat conversation. The editor shows
that name on the port, colours it, and only offers to connect ports that
match.
You can add these names yourself in the admin UI, or a module can ship them
in code. Nothing existing breaks: every workflow you have saved keeps running
exactly as before.
FlowDrop 2.3.0 is a feature and hardening release. Loops become a defined,
predictable part of the language, workflows gain a proper input/output
interface, and a long list of silent misbehaviours — several of them
shipping since the first 2.x release — are fixed.
This is a testing release. Most of the work in it is behind the scenes — a large
expansion of the automated test suite and the checks that run on every change —
but a handful of things do change for you, and two of them need a person to
look at them. Please read the first section before upgrading.
Full technical detail is in the CHANGELOG; upgrade specifics are
in UPGRADE.md.
Every side-effecting node type now ships a confirmation policy instead of deriving one (flowdrop_memory, flowdrop_node_processor, flowdrop_interrupt, flowdrop_node_type)
Agent loops stop being a three-node privilege, and a message list stops being
"an array". Re-entry was never node-specific in the engine — the edge
classifier, the compiler, the job generator and the orchestrator all keyed on
the handle suffix, and only the port declaration confined loops to foreach,
Confirmation becomes governance. Requiring operator approval is a
governance/security decision, not a processor property — a "harmless" node may
need confirmation for purely business reasons nothing in its code can know. The
2.1.0 requires_confirmation tri-state therefore grows into a confirmation
governance map on every node type: a policy (ask / skip / unset = derive
Human-in-the-loop confirmation for side-effecting nodes. A node type can now
require operator approval before it executes: the run pauses on an ordinary HITL
interrupt, an approve lets that exact execution proceed once, and a decline routes
down the node's normal error channel instead of failing the run. The gate covers both execution planes — nodes scheduled by the graph and nodes invoked as
The 2.x line is stable. The public API is frozen from here. Everything the BC policy promises starts at this tag — the
alphas and betas were deliberately outside it and took breaks freely.
The 2.x line moves from alpha to beta. No new features: this release exists
because the module did not actually run on the PHP version most of its audience
is on. composer.json advertised PHP 8.2 and CI tests 8.3, but 89 promoted
constructor properties across 50 classes were declared readonly beneath
Drupal base classes that use DependencySerializationTrait — a combination that
The outbound half of external integration lands: a Call and Wait node that
starts work on another system and pauses the run until that system calls back,
answered through a new machine-facing callback route. Alongside it, flowdrop_orchestration_connector — the inbound half — is realigned so that
external invocation works end to end for the first time; webhook push
A single-fix release, out one day after alpha13 because that release is what
broke this. Upgrade straight from alpha13 if you declare any workflow input
port — mixed is the port editor's default type, so this is more likely to
affect you than the one-line summary suggests. No schema updates, no post_update hooks, no configuration changes.
Credentials stop being stored in workflow config, plus three issue-queue fixes
and a repair of three editor features that were dead against live routes (RUN,
session reset, operator signals). Several post_update hooks run on drush updatedb: the playground auto_run one only fills in a key that was
never set, so an explicit choice is preserved, and the rest strip configuration
Hardening release, three threads. One: the launch contract is now explicit
end to end — launch-input errors name the accepted set, supplied values are
type-checked against the workflow's schema snapshot before any pipeline work, wait on an async-orchestrator workflow is refused instead of silently
ignored, and hidden output ports stop delivering (the canvas is the contract).
Feature release. Consolidates workflow routing onto one mechanism — named
branches — after a loop-guard bug opened into two findings of the same shape: data.condition edge expressions honoured by only one of two executors, and
an editor type checker whose undeclared types were compatible with nothing.
Also closes three config-schema conformance gaps that broke strict validation
Bugfix release. Fixes a fresh-install defect on flowdrop_pipeline: the base
fields that flowdrop_runtime (snapshot_id) and flowdrop_session
(session_id) contribute via hook_entity_base_field_info() were never
physically installed on fresh sites, so pipeline-linked snapshot and session
Feature release. Follows up 2.0.0-alpha8's layout work: a node's config form
now opens in the right sidebar by default (was a centered modal), matching
the bundled library's own default and sitting alongside the console / AI
Assistant group. Still a seeded default, not a lock — the ui settings category
stays exposed, so users can move it back. Existing sites are migrated by
Feature release. Editor layout defaults, all in flowdrop_ui_components: a
node's config form now opens in a centered modal and the console / AI
Assistant group docks in the right sidebar (instead of the bottom panel),
and the editor theme follows the OS light/dark setting. These are seeded
defaults, not locks — the ui settings category stays exposed so users can
Feature release. Two authoring gains at the tool/workflow boundary: data-wired
inputs on tool nodes let an author feed ground-truth context into a tool the
model must not author (withheld from the model, resolved from run state and
injected at invoke time), and exposed workflow inputs now carry
author-supplied title/description/examples in their derived schema contract.
Plus a config-schema validation fix for polymorphic schema-fragment leaves. No
Feature release. Adds the pieces to author an agent loop as a graph — a
provider-neutral reasoning contract in core with reason and tool_invoke
nodes — plus a Stop terminal node, in-editor trigger configuration, and
named dynamic ports on Prompt Template. Also repairs a gateway
branch-gating regression and two latent correctness bugs. No stored-format
Hardening release. Node processors that return a value json_encode cannot
represent now fail loudly at execution time instead of silently corrupting to an
empty object once persisted. No API or stored-format changes from 2.0.0-alpha3.
Bug-fix release closing two regressions introduced by the 2.0.0 node-metadata
slimming (the data.metadata.node_type_id anchor rename). No API or stored-format
changes from 2.0.0-alpha1.
⚠ Upgrade to the latest 1.6.x first — it is a mandatory security release. 1.4.x and 1.5.x carry security fixes that first reached the stable line in 1.6.0, so the supported path into 2.0.0 is via 1.6.x (don't jump straight from 1.4.x/1.5.x).
HTTP API stability. Endpoints under /api/* are @internal — they serve the bundled @flowdrop/flowdrop JavaScript library and are not a public REST contract. Shape changes between minor releases are expected and are listed below for completeness, not as deprecation notices. See BC Policy → HTTP API Stability.
Dynamic input/output ports: Node types can now declare dynamic ports whose number and names are determined at runtime by configuration. Introduces DynamicPortTrait for node processors, a ReservedName constants class to prevent name collisions, and a new DataMapper node processor that maps input fields to output ports dynamically.
New flowdrop_memory module: Persistent memory system for workflows, enabling nodes to store, retrieve, and delete stateful data across executions. Includes:
First stable release of FlowDrop. All public APIs are now covered by semantic versioning backward compatibility guarantees. See docs/api/BC-POLICY.md for details.
Trigger module stabilized: flowdrop_trigger promoted from lifecycle: experimental to lifecycle: stable. TriggerManagerInterface, FlowDropTriggerConfigInterface, and FlowDropEventTypeInterface marked @api with full semver BC guarantees.
First beta release. FlowDrop is now feature-complete for 1.0 and entering stabilization. No new breaking changes are planned — only bug fixes and documentation improvements from this point forward.
BREAKING: Standardized all API response envelopes to { success, data, error } format using new ApiResponseTrait. The message, code, and count fields have been removed from responses.
patch_mode for EntitySave node processor: When enabled, loads the existing entity by ID and merges only the specified field values, preserving all other fields. Prevents validation failures on required fields during partial updates.
The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.
