Memory settings
The ceiling on a single stored memory value, and how to raise it per site or per backend.
Nodes that accumulate state across a run — an agent's conversation_buffer, a
counter, a cached lookup — write it through FlowDrop's memory service. Each
stored value is serialised to JSON, and a value larger than the configured
ceiling is refused rather than saved.
Where the setting lives
Administration › FlowDrop › Memory Settings, at
/admin/flowdrop/memory/settings. It needs the administer flowdrop
permission.
Maximum value size (bytes) is the largest serialised value any memory
backend will accept. It defaults to 1048576 (1 MiB), which is also the value
used when the key is absent, so a site that never touches it behaves exactly as
before.
The same value is flowdrop_memory.settings:max_value_bytes in configuration:
drush config:set flowdrop_memory.settings max_value_bytes 4194304Per-backend overrides
A backend can be given its own ceiling at
flowdrop_memory.settings:backend_config.<backendId>.max_value_bytes, for the
cached, entity and static backends:
drush config:set flowdrop_memory.settings backend_config.entity.max_value_bytes 2097152Precedence: a write resolves the flat max_value_bytes first, and a present
override for the backend being written to replaces it. With no override, the
flat setting applies; with no flat setting either, the published default of
1 MiB applies.
The backends never had the same real ceiling underneath: entity is bounded by
its column type, static only by PHP's memory limit. Raise the entity
override with more care than static's.
A non-numeric value — the kind an unvalidated settings.php override can
produce — is logged once and falls back to the default rather than quietly
restoring the old cap. It does not throw: this is the write path that already
throws for a genuinely oversized value.
What a workflow sees when a value is over the cap
The write throws, and the message names the key, the scope, the limit and the size given:
Memory value for key "conversation_buffer" in scope "pipeline" exceeds the
maximum allowed size of 1048576 bytes (1064000 bytes given).That exception fails the node, and with it the run — even where the work the run was doing is already finished. An agent that has produced its answer and is appending the last turn to a buffer nobody will read again is the case this bit in practice, which is why the limit is a setting.
Raise the ceiling if workflows fail with exceeds the maximum allowed size.
A node that needs to stay under it instead can ask for the effective limit
before writing, with MemoryManager::getMaxValueBytes($backendId), and trim
or roll the value itself.