50 lines
3.6 KiB
Markdown
50 lines
3.6 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,
|
|
channel layer and task locks each take a prefix a settings module could set — none of them from
|
|
the environment. But its own code also writes under names fixed in the code: presence keys, a
|
|
recently-used-workspaces key that is updated by default, rate-limit keys, and a health check that
|
|
reads the task queue by its unprefixed name. 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 generates on first start and keeps on its data volume; 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.
|
|
|
|
*On review.* An independent review re-read both images and confirmed the chain above step by step,
|
|
corrected which baserow keys are movable (the task-lock prefix is, through a settings module), and
|
|
tightened the bed: it now asserts baserow said it chose its own cache and that the cache challenges
|
|
for its password, rather than looking for the absence of errors, which a startup race could have
|
|
produced. Upgrading a running node drops any task still queued in the shared cache; the provider
|
|
removes the consumer's login when the grant goes, a path this change does not exercise.
|
|
|
|
*Proven, 2026-09-22.* The two-node bed passes with baserow as the catalogue shapes it. On the way it
|
|
found the module's data directory narrower than the image ships it: the cache baserow runs for
|
|
itself runs as another user, who could not reach its own directory under a directory closed to
|
|
everyone but baserow's user. The module declares the image's mode now. The shared cache had hidden
|
|
this: baserow never ran its own until this change.
|