35 lines
2.4 KiB
Markdown
35 lines
2.4 KiB
Markdown
# 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.
|