Reading the catalogue is a write, so the operator shell cannot be pointed at a follower

Type

Design tension — two correct decisions meeting

Found while

SAPE-27

Triage

Defer

Status

Open

Severity

Medium in operation, zero in correctness — nothing is wrong, something is unreachable

Description

store.WhatIsHere and store.Explore each record a ChangeRead entry. That is deliberate and it is one of this project's better decisions: the audit trail does not stop at writes, so "who looked at what" is answerable, and the operator shell's promise that every access it makes goes into the change log with a name against it rests on exactly this.

A follower is read-only, and read-only here means it applies entries and creates none. An entry is an entry regardless of what it describes. So both calls are refused on a follower with code read_only, and the consequence is concrete: sapedb shell pointed at a follower cannot list its collections.

Invoking a declared read-only operation still works, because invoking one records nothing. Today that is the only way to read a follower — which means you can read what somebody already thought to declare, and nothing else.

Why this is a tension and not a bug

Both halves are right on their own terms:

• Auditing reads is why the operator shell can be trusted at all. Making Explore stop recording would quietly weaken the one surface built to be accountable.
• A follower that writes entries of its own is no longer following anything — its log would diverge from its leader's, which is the one invariant replication has.

So the fix is not to weaken either, but to add the missing third thing: a catalogue read that does not record, kept distinct from the one that does, with the difference visible at the call site rather than implied. Whoever builds it has to answer what the audit trail should say about a read on a machine that cannot record — probably that the leader is where such a record would belong, which is a larger question than this issue.

Triage

Does it lose data, break a promise on a public surface, or stop somebody installing and running? No. Nothing is lost, nothing published is contradicted — follower mode is new today and this limitation ships documented with it, in the CHANGELOG, the README and the godoc — and installing and running is unaffected.

Defer, and the tension is worth naming rather than smoothing: replication is in 1.0.0 by product decision, not by that triage, so a purely rule-based answer sits a little oddly here. A follower you cannot inspect with the tool built for inspecting things is a real operational gap on a feature the release is choosing to advertise. It still defers, because the rule is the rule and applying it only when convenient is how a backlog stops meaning anything — but the person running the first follower should read this page before they need it, not after.

Workaround, stated because it is the honest one

Point the shell at the leader. The catalogue is replicated, so the leader's answer describes the follower's contents too — up to replication lag, which is asynchronous and unbounded by design (see SAPE-27's scope).