fix: BullMQ fails on Dragonfly without --default_lua_flags=allow-undeclared-keys #273
Description
Problem
With Dragonfly's default settings, BullMQ Lua scripts fail when processing jobs:
ERR Error running script (call to ...): @user_script:498: -ERR script tried accessing undeclared key, key: bull:smoke:2
Reproduced locally with Dragonfly latest using the same flags as docker/compose.yml (--maxmemory --proactor_threads --cache_mode) and prefix: "bull", with both bullmq 5.81.5 / ioredis 5.11.1 and bullmq 6 / ioredis 6. So this predates the dependency upgrade in #272.
Adding --default_lua_flags=allow-undeclared-keys (Dragonfly's documented setting for BullMQ) fixes it: enqueue → process → complete works.
Affected configs
docker/compose.yml,docker/compose.dev.yml,.devcontainer/compose.ymldeploy/k8s/rox/20-dragonfly.yaml(production,dragonfly:v1.25.1) — needs checking whether the production delivery queue is actually affected (backend logs / stuckbull:*keys)
Fix
Add --default_lua_flags=allow-undeclared-keys to all Dragonfly configs.
Activity
fix: read DRAGONFLY_URL as Redis URL fallback and warn on connection …
sasagar commentedon Oct 13, 2026
Additional finding: production does not use Dragonfly at all
Production has no
bull:*keys and backend logs show no Lua errors. Root cause:DragonflyCacheAdapter.tsandActivityDeliveryQueue.tsread onlyREDIS_URLdocker/compose.ymlanddeploy/k8s/rox/secret.example.yamlsetDRAGONFLY_URLlocalhost:6379fails → caching disabled and synchronous delivery fallback, logged only atdebuglevelFixed in #274: accept
DRAGONFLY_URLas a fallback and log connection failures atwarn.Once deployed, the queue will actually start using Dragonfly, so the Lua flag from this issue must be applied to the cluster first.
github-actions commentedon Oct 13, 2026
Closed by #274 (merged to dev).