v5.3.4

Transactions and replication

• abort() no longer spins forever on reads made after commit. A read made after commit had no native handle but still added a read reference, and nothing could ever release it. DatabaseTransaction.abort() waits for that count to reach zero, so it looped at 100% CPU. In one case an HTTP worker stayed pegged for hours and its replication subscriptions stalled until restart. A read reference is now counted only when a handle was taken, and a reference from an earlier handle is ignored on both RocksDB and LMDB. (#3337)
• Retried replicated writes no longer re-apply a duplicate that already committed. On RocksDB, a replicated write that retried after a commit conflict skipped the audit duplicate checks. If another delivery of the same write had already committed, the retry applied it again, and a CRDT add counted twice. 5.3.3 fixed this when the duplicate was at the record head. It now also covers a duplicate under a newer write, beside an out-of-order sibling, and on the replay that runs while a read snapshot is open. (#3453)
• Receivers skip relayed duplicates of a record's current version without reading the transaction log. A record that arrived by base copy has no transaction-log entry. On RocksDB, checking a duplicate of it read to the end of the origin's log, which could take seconds per write. The duplicate was then logged again and re-sent to every peer, so an old stretch could replay indefinitely. A replicated write that matches the stored record's origin, version and log key is now skipped on first delivery, with no log read and no new entry. (#3476)

MQTT

• Subscribers on other worker threads keep receiving non-JSON payloads. With threads.count > 1, a subscriber on a different worker than the publisher stopped receiving after the first payload that was not a JSON object (text, a JSON array or string, or binary), while staying connected. These payloads are now delivered correctly. A delivery the server cannot send now closes the connection so the client reconnects, instead of leaving a silent connection open. (#3446)
• Durable single-record subscriptions no longer resend the record on reconnect. A QoS 1 or 2 session subscribed to one record (Table/<id>) got that record again on every reconnect, even when nothing had changed. At QoS 1 that was a duplicate. At QoS 2 it arrived beside the replayed PUBREL for the same message, which breaks exactly-once delivery. Resume now skips the current value, as it already did for QoS 0 and wildcard topics. (#3440)

Full changelog: v5.3.3...v5.3.4