--- title: "Memory settings" description: "The ceiling on a single stored memory value, and how to raise it per site or per backend." source: https://flowdrop.io/docs/drupal/memory-settings site: FlowDrop documentation --- # Memory settings {/* Claims on this page were read from apps/fddo (branch feature/26-stable-closeout): modules/flowdrop_memory/config/install/flowdrop_memory.settings.yml — default max_value_bytes: 1048576 modules/flowdrop_memory/config/schema/flowdrop_memory.schema.yml — backend_config..max_value_bytes keys modules/flowdrop_memory/flowdrop_memory.routing.yml — /admin/flowdrop/memory/settings modules/flowdrop_memory/src/Form/MemorySettingsForm.php — the form fields and their descriptions modules/flowdrop_memory/src/Service/MemoryManager.php — MAX_VALUE_BYTES, getMaxValueBytes(), set()'s refusal CHANGELOG.md [2.6.0-alpha3] "The memory value ceiling is a site setting" UPGRADE.md "New setting: the memory value ceiling is configurable" */} 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: ```bash drush config:set flowdrop_memory.settings max_value_bytes 4194304 ``` ## Per-backend overrides A backend can be given its own ceiling at `flowdrop_memory.settings:backend_config..max_value_bytes`, for the `cached`, `entity` and `static` backends: ```bash drush config:set flowdrop_memory.settings backend_config.entity.max_value_bytes 2097152 ``` **Precedence:** 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: ```text 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.