First, there wasn't a huge amount of logic change here so no worries on rewriting. Most of the refactoring was to move functions around to a logical ordering along with the split between mem3_rpc which helps me reason about which nodes specific functions are executed on.

Second, even after sleeping on this I'm still pretty sure your version isn't correct. Given that our history is basically a list of (A -> B) tuples that record the update_seq on A and B. I think the issue is that there's a subtlety on that relation that is going under the radar. Specifically, the tuple tells us what update_seq on B fully contains the paired update_seq on A. So when you say this:

"It's completely irrelevant what data from A was written into B."

I'm pretty sure one of us is 100% reversed on this relationship or we're labeling nodes differently. Given the above example though I'm pretty sure your statement is reversed. The A->B pair is important because it is *precisely* what data from A was written into B. The only claim we can make there is that update_seq B wholly contains update_seq A on a different shard copy. What I think you are referring to is that given the (A -> B) tuple, knowing update_seq B tells us nothing about what the update_seq A may refer to.

Another issue that seems wrong is this bit:

"I fully intend to look at 'values written for B'."

Which I'm pretty sure is a response to this:

"So you're comparing values from A against values written for B."

I think you missed the finer point on that. Getting rid of our A/B denotations, lets say we have two types of data. Call them Foo's and Bar's. We then have an index of (Foo, Bar) tuples. My assertion is that you're creating an instance of Foo and attempting to compare it against instances of Bar.

Or more specifically for our use case, you're taking an update_seq from db1 and attempting to compare it to update_seq's on db2. There both integers but from two different logical domains.

Or I could be completely wrong as well.