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

04-ISSUES/081-a-cache-consumer-does-not-use-the-login-it-was-granted/00-report.md

@@ -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

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

@@ -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.