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

## Symptom

Two catalogue modules require the cache and are given a login and a password under a keyspace of
their own ([issue 080](../080-a-cache-grant-lets-the-consumer-flush-the-server/00-report.md)),
and neither tells its software the login: each hands it the host, the port and the password only,
so the software authenticates as the server's default user and writes wherever it likes — or is
refused, if the default user is closed. The grant is honoured by the provider and ignored by the
consumer.

Found on review of issue 080, by reading the two manifests. Not run: no bed installs either
module against the catalogue's cache and reads what it wrote.

## Why it matters beyond the instance

A grant is two ends agreeing. The provider's end is checked by the grant bed; the consumer's end,
that the software actually presents what it was given, is checked by nothing but the module
working — and a module that works as the default user works.

## What would close it

Each module passes the login it was bound (`${bound:redis-cache:as}`) to its software's username
setting, and a bed installs one of them against the catalogue's cache and reads back that its keys
sit under its login.