ROLE reports a non-zero replication offset on a master with no replicas (redis reports 0)

[TinDang97]

ROLE / master_repl_offset is non-zero on a master with no replicas

Redis holds master_repl_offset at 0 until replication is actually in use —
the replication backlog is only created when the first replica attaches, so
until then there is no stream and nothing to offset into. moon advances the
offset on every write from the moment it starts.

Reproduction

moon --shards 1 and redis-server 8.6.1, both fresh, no replica ever attached:

== ROLE on a fresh master, no writes ==
moon:  master / 0
redis: master / 0

== ROLE after 50 writes, still no replica ==
moon:  master / 1441        <-- diverges
redis: master / 0

== master_repl_offset ==
moon:  master_repl_offset:1441
redis: master_repl_offset:0

Impact

This is the FAIL: ROLE on a master row in scripts/test-consistency.sh
(added by #471) — it has been failing on every run, not flaking. Client-visible
consequence: tooling that reads a non-zero master_repl_offset (or the second
element of ROLE) as "this instance is participating in replication" gets a
false positive on a standalone moon. Monitoring that graphs master-vs-replica
offset lag sees a master racing away from an offset that does not exist yet.

Notes

Not urgent and not data-affecting; filing it so the standing red row in the
consistency harness is tracked rather than absorbed as background noise. The
question to settle is whether moon's offset should stay at 0 until a replica
attaches (matching redis, and meaning the internal write counter and the
reported offset become separate things), or whether the divergence is
deliberate — in which case the harness row should be a documented exception
with the reason, so the harness can go green.

Pre-existing: reproduces on main, unrelated to the branch that surfaced it
(#636 DEBUG DIGEST).

[TinDang97]

Confirmed on main @ 54f71b46, freshly built, on a port verified free and whose listener PID matched the spawned child:

main @ 54f71b46, fresh:      master / 0
after 50 writes:             master / 1441
offset: master_repl_offset:1441

Byte-identical to the branch that surfaced it, so it is not introduced by #636.

[TinDang97]

Duplicate of #536, which reported the same divergence on 2026-08-17 with the same reproduction. I missed it when filing — should have searched the existing issues first.

The one datapoint here that was not already on #536 (still reproduces on main @ 54f71b46, 2026-08-23) has been carried over as a comment there. Tracking continues on #536.