Reading back over the report on ITS-8281, the reported behavior would have been a collision of generating a new contextCSN as well as duplicating the producer's SID. So it's generated contextCSN would have masked the one it never committed from the original master.

However, the point still stands that the contextCSN entry is *not* being written to the access log by the first server (A) here. It is only being written by the second server (B).

So in the scenario that is supposed to be addressed by the fix - a second MMR node with an uninitialized database is in its initial refresh, it wouldn't be receiving contextCSN updates through the access log because they simply aren't there.

To me the logical behaviour would be that a new node would remain without a recorded contextCSN until it receives the sync cookie along with the refreshDone message. Sending an explicit contextCSN update after every single accesslog entry seems an awfully expensive and unintuitive approach to fixing a refresh issue.

TL;DR: The objection raised in scenario #3 stands if you are initializing a new MMR node, since. Or in a single master + replica scenario.

Or to rephrase, if these entries are intended and necessary, shouldn't they be generated on the original server as well? This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.