Files
hq/04-ISSUES/081-a-cache-consumer-does-not-use-the-login-it-was-granted/01-diagnosis.md
T

2.4 KiB

Diagnosis — 2026-09-22

Read from the two pinned images rather than from their documentation.

  1. Presenting the login is not enough. The cache confines each consumer to keys under its own login (issue 080). A consumer that sends the login but writes its keys under names of its own choosing is refused on every write, which is worse than the default user it replaced. So the question for each module was whether its software can put every key, and every pub/sub channel, under the login.
  2. n8n cannot, and in its shipped mode does not need to. It has a username setting, and its queue and cache keys take configurable prefixes, so the keys could move. Its pub/sub channels are fixed names in its code, and a per-consumer grant allows no channels. Those channels are used only in queue mode. The catalogue runs n8n in its regular mode, where it opens no connection to the cache at all: the requirement bought a login nothing used.
  3. baserow cannot. It has a username setting, and its caches, task queue, results, scheduler and channel layer each take a prefix a settings module could set. But its own code also writes through raw connections under fixed names: rate-limit keys, singleton locks, a queue-size health check, an async client. Those cannot be moved without changing baserow. Its container, run without a cache address, starts a cache of its own inside the container, under a password it makes itself; that is its standard single-container deployment.
  4. So neither module takes the shared cache. baserow uses its own; n8n needs none until someone runs it in queue mode, which would need a cache of its own for the same pub/sub reason. The shared cache remains for software that keeps its keys under the login it is given, which the grant bed proves.

How it is checked: a mesh-lab unit test reads every catalogue module that requires the shared cache and fails unless it hands its software the login it was granted; it fails on the catalogue as it was, naming both modules, and passes now. The two-node bed runs baserow as the catalogue shapes it and asserts its own cache answers inside its container and that baserow logged no refusal. The same bed had carried a copy of baserow that took the shared cache with the password alone, and passed only because it never looked at the cache.

Located in: the two modules. Not a decision: a module choosing its own cache over a shared one it cannot share is the module's.