Visitar URL original
Replicated apply does not advance PageManager.publicationSequence: a replica read can mix chunks of two commits · Issue #10941 · ArcadeData/arcadedb · GitHub
Skip to content

Replicated apply does not advance PageManager.publicationSequence: a replica read can mix chunks of two commits #10941

Closed

Description

@robfrank

Summary

On a replica, the replicated apply of a transaction (TransactionManager.applyChangesPages) writes pages into the read cache without advancing PageManager.publicationSequence. That counter is what the #9369 check uses to detect a commit whose pages are only partly published (PageManager keeps it odd while the pages of one transaction are being published). Because the replicated apply never moves it, a reader on a replica cannot tell that a multi-page record (a chunk chain) is half updated, and can assemble one record from the chunks of two different commits.

Where (origin/main)

How it was found

Found by reading the code while investigating a transient read failure on replicas (a reader walking a growing chunk chain while a replicated apply was writing it). The affected reader recovered on its next attempt, so no wrong result was observed, but nothing in the replica path guarantees that.

Expected

The replicated apply publishes its pages under the same protocol as a local commit (odd/even publicationSequence around the whole transaction), so the #9369 check also protects reads on replicas. A regression test: on a replica, read a multi-page record in a loop while the leader repeatedly rewrites it with a different size; every read returns one of the committed versions, never a mix.

Activity

  1. added this to the 26.11.1 milestone on Oct 29, 2026
  2. added
    severity:majorA feature is broken or returns wrong results, with no practical workaround
    on Oct 29, 2026
  3. self-assigned this
    on Oct 29, 2026
  4. added
    concurrencyThreading / concurrency / MVCC
    engineCore engine: document/schema API
    haHigh availability / replication (Raft)
    severity:minorCosmetic, documentation, edge case, or a workaround exists
    storageStorage/paging/WAL engine layer
    on Oct 29, 2026
  5. robfrank commented on Oct 29, 2026

    @robfrank
    CollaboratorAuthor

    Additional evidence from a three-node load test (3 writers x 15,000 mixed insert/update/delete ops on node 0 with records that grow into chunk chains, concurrent queries on every node; image built from current main + a feature branch, 2026-10-29):

    • On followers only (the leader logged none), plain scans log Scan of bucket N skipped M record(s) that could not be read ... result may be incomplete: 1 to 19 skipped records per follower per run. A SELECT / GROUP BY on a follower therefore silently misses records while a replicated commit is being applied; the same records read fine once the follower caught up.
    • A record lookup on a follower occasionally fails with BrokenChunkChainException (LocalBucket.loadMultiPageRecord), 1-3 per run, transient, again only on followers.
    • Both match the cause described above: the replicated apply does not move publicationSequence, so a follower reader cannot detect a half-applied chunk chain.

    Reproduced in 3 of 4 runs before any mitigation on the reading side.

  6. added a commit that references this issue on Oct 30, 2026
  7. robfrank commented on Oct 30, 2026

    @robfrank
    CollaboratorAuthor

    A replicated apply wrote pages into the read cache without moving PageManager's publication sequence, so a replica could not detect a half-published transaction. The apply now brackets its pages with the publication calls, and the sequence is driven by a count of publications in flight so overlapping ones cannot turn it even early.

    Still open: The end-to-end two-node reader loop from the issue was not reproduced: the invariant is tested at the engine level only. No follow-up issue.

    Fixed by #10989.


    ❤️ Thanks for helping make ArcadeDB better! ArcadeDB is free and open source, sustained by its community. If it's useful to you or your company, please consider becoming a sponsor to keep development going.

  8. removed
    in progressThe team is actively working on this issue
    on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugconcurrencyThreading / concurrency / MVCCengineCore engine: document/schema APIhaHigh availability / replication (Raft)severity:majorA feature is broken or returns wrong results, with no practical workaroundseverity:minorCosmetic, documentation, edge case, or a workaround existsstorageStorage/paging/WAL engine layer

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions