[ldt1996]

⊙ Problem

On 5.4, a node that restarts, restarts its HTTP workers or reconnects replication delivers replicated MQTT messages to its live subscribers a second time. A checkpoint-grade route resumes exactly below the origin's certified floor (#1092), which trails what the node applied by up to an originFloors interval, so the origin re-sends that part of its log. Record writes in it are dropped as duplicates; publishes were logged and delivered again.

💡 Solution

• Bumps core to Skip a replicated publish the receiving node has already logged, so a restart or reconnect doesn't deliver it twice harper#4339 (stacked on Keep a record's version when a message older than it is published harper#4384), which skips a replicated publish whose entry the origin's log here already holds. Resume stays floor-only, so a late commit below the applied position is still re-sent and applied once.
• Adds a cross-node suite for the three ways a node's replication resumes, with a generic exported-table fixture (schema, config, diagnostic resources).
• Notes in replication/DESIGN.md that the leading-duplicate skip ties only stored records, so publishes rely on core's check.

⚖️ Alternatives

• Probe only below the receiver's resume cursor — the cursor is per connection and per subscription node, so relayed origins, replayed frames and another connection's re-sends would still be delivered twice. Core's apply owns the check (#4339).

✅ Verification

• replicatedMessageRedelivery.test.mjs: a publisher on A, clean-session QoS 0 subscribers on B and A. A restarts, B's HTTP workers restart, B restarts. Each case asserts no duplicates on either node, nothing sent after the interrupted side is back is lost on B, and B logged each of A's messages once. It needs a second loopback address, so it has not run locally; CI runs it.
• The same three restarts with two nodes on one host (distinct ports), 20 messages/s, on this branch's base and head:

restart	base: duplicates at B's subscriber / logged twice on B	fix
A	118 / 118	0 / 0
B's HTTP workers	0 / 125 (re-sent before the subscriber was back)	0 / 0
B	92 / 92	0 / 0

Nothing sent after B was back was lost in any run; a node restart still delivered the messages sent while B was down.

Performance: no cost on in-order publishes: HarperFast/harper#4339 is stacked on HarperFast/harper#4384, so only a message at or below its topic's record version reads the log (measured on #4339: 17.9–18.0 µs per replicated publish vs main 18.0–18.2).

PR QA: skipped @ 8c9d9a1 — dispatch is not available in this session

_{🤖 Generated by Claude Opus 5.5 (Claude Code); posted via @ldt1996.}

Release target: v5.4 — fixes a regression in the 5.4 betas from #1092's floor-only resume; 5.3 has none

Depends-on: HarperFast/harper#4384, HarperFast/harper#4339

Related PRs: #1358 independent
Complexity: medium

Deferred findings

• 3054506b6609bc66 minor data-integrity — core — Core publish dedupe may drop a second same-topic publish sharing one transaction version, or re-deliver after receiver log pruning — NOT FILED

_{Review-Coverage: authored=claude; ran=codex,gemini,gemini-carbon; late=gemini-carbon:adjudicated; adjudicated=domain; blocked=cursor-composer(not-installed); declined=cursor-grok,muse; rounds=3; full=1 @ 8c9d9a1}

_{Review-Attention: read ~3m (decisions: publish-dedupe-layer, perf-cost, shared-nodes-across-cases) @ 8c9d9a1}

[kriszyp]

_{🤖 Reviewed with Codex}

[kriszyp]

[major] Preserve the current base’s core fixes when repinning

The actual submodule delta from fe3b268e to 6a066933 changes 65 files and removes eight base-side commits, including restore-on-restart (#3987), the mTLS live-subscription fix (#4069), and analytics optimizations. This is a runtime rollback, not just ancestry divergence: core/dataLayer/rocksdbBackup.ts:643-663 no longer reads on_restart, and core/resources/Resource.ts:1217-1218 again refuses a refreshed principal without a role. Consequently, restoring a component-held database with on_restart=true loses its supported scheduling path, and certificate principals admitted without an hdb_user lose their subscriptions again. Rebase the core companions onto the current base core and repin to a commit containing both sets of changes. Confirm the resulting core tree retains these fixes before landing.

[kriszyp]

[minor] The worker-restart case does not exercise replay when replication uses the pool

With the replication pool enabled, this case does not exercise replication replay: restartHttpWorkers only rolling-restarts HTTP workers, while integrationTests/cluster/clusterShared.mjs:248-251 documents that pool-on CI legs put replication on replication.threads workers and replication/DESIGN.md:109 states those pool workers own the sockets. Trigger: run the cluster suite with HARPER_CONFIG setting replication.threads > 0, remove core's isMessageLogged drop, and this case still passes because B's A-socket never disconnects, never resumes floor-only, and never re-streams a message; only the origin-restart and node-restart cases still cover the drop. Fix by making the pool case restart the replication owner (or pin this case pool-off / branch on replicationPoolActive()), so the named scenario reaches the resume it claims to test.

[kriszyp]

[minor] The log-count assertion can conceal messages missing during B’s restart

The log completeness check cannot detect messages dropped from the segment a clean-session subscriber legitimately missed. In the node-restart case the subscriber check starts at resubscription (integrationTests/cluster/replicatedMessageRedelivery.test.mjs:152 and integrationTests/cluster/replicatedMessageRedelivery.test.mjs:162), so messages A published while B was down are covered only by LoggedMessages, but that check counts distinct versions for the whole topic against publisher.n - backUpN; pre-interruption entries count toward the threshold, so if replay drops D of the down-time messages the distinct count is n - D and the assertion still passes whenever D <= backUpN, which already includes both the pre-interruption count and the down-time count itself. Trigger: make B's resume drop the messages committed on A during B's restart; the subscriber never sees them, no duplicate is logged, and the suite passes despite B's origin log missing that segment. Check a segment-specific oracle instead, for example the distinct versions at or after the interruption point, not a topic-wide count.