Issue 081 resolved: neither cache consumer can keep its keys under its login, so neither takes the shared cache

2026-09-22 12:27:12 +02:00
parent f1e3925009
commit 5d1a0372cb
2 changed files with 36 additions and 1 deletions
@@ -1,7 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-22
 located-in: [mesh-catalog modules/n8n, mesh-catalog modules/baserow]
 fixed-by: mesh-catalog multiple-fixes (neither module takes the shared cache — baserow runs its own, n8n in its shipped mode needs none); mesh-lab multiple-fixes (a check that every catalogue module taking the cache presents the login; the two-node bed asserts baserow's own cache answers)
 ---
 # 081 — A cache consumer does not use the login it was granted
@@ -0,0 +1,34 @@
 # 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.