Hang introduced by #5269, (a0f93cb) (fix included) about sanity

[bjoerge]

Hi, thanks for the thorough investigation and the proposed fix @sarahsvedenborg! Unfortunately your proposed fix breaks one of our unit tests, so we need to spend a bit more time on understanding why this happens for you. This is the first time I hear about this beging an issue, so suspect it might be something about your particular setup that triggers this.

I understand that it's difficult to create a minimal reproducible case, but any more details about your schema/setup would be of great help and also allows us to capture your case in a unit test to make sure we don't regress. Feel free to relay any details through support channels.

[stian-svedenborg]

@sarahsvedenborg is working on producing a minimal test-case, but I have a question regarding the failing unit test.

Are you sure the unit test is working as intended?

The proposed fix has one functional difference to the existing reconcile, namely that it continues to reconcile objects within loops, the old version does not and will give up on reconciling objects or arrays encountered in the second iteration of a loop and simply pick "next" even if subobjects of next could still be reconciled, could this be the reason for the failing unit test?

To illustrate:

const objectCreator = (differentiator) => {
  const root = { id: "root" } // will be different if differentiator is different
  const a = { id: "a" }   // will be different if differentiator is different
  const b = { id: "b", diff: differentiator }  // will be different if differentiator is different
  const c = { id: "c" }  // will never be different

  root.a = a;
  root.a.b = b
  root.a.b.a = a; // loop
  root.a.b.c = c;

  return root
}

const previous = objectCreator("previous")
const next = objectCreator("next")
const reconciledOld = immutableReconcileOld(previous, next)
const reconciledNew = immutableReconcileNew(previous, next)

// Current Behaviour
assertNotSame(previous, reconciledOld)
assertNotSame(next, reconciledOld)
assertSame(previous.a.b.c, reconciledOld.a.b.c)
assertNotSame(previous.a.b.a.b.c, reconciledOld.a.b.a.b.c) // (Suboptimal) Equal objects nested within loops are not retained in the second iteration of the loop.
assertNotSame(reconciledOld.a, reconciledOld.a.b.a) // Loops inside reconciled objects are not retained. 
assertSame(next.a.b.c, reconciledOld.a.b.a.b.c) // This is because the old reconcile always picks "next" when hitting a node that it is already resolving.

// Proposed behaviour
assertNotSame(previous, reconciledNew)
assertNotSame(next, reconciledNew)
assertNotSame(next.a, reconciledNew.a) // A sub object of root has changed, creating new object
assertNotSame(next.a.b, reconciledNew.a.b) // A sub-object of root.a has changed, creating new object
assertNotSame(next.a.b.c, reconciledNew.a.b.c) // root.a.b.c is has not changed, therefore reuse.
assertSame(previous.a.b.c, reconciledNew.a.b.c)   

assertSame(previous.a.b.a.b.c, reconciledNew.a.b.a.b.c) // The new reconcile will retain reconcilable objects also within loops.
assertSame(reconciledNew.a, reconciledNew.a.b.a)  // This is because it retains the loop.
assertSame(previous.a.b.c, reconciledNew.a.b.a.b.c)

If this is the reason for the failing unit-test I would propose changing the test, as the new reconcile will be both faster and reconcile more objects.

[bjoerge]

Great observations @stian-svedenborg – Think you're absolutely right here. I'll set aside some time today to integrate your proposed unit test into our test suite and make a PR based on @sarahsvedenborg's fix. Thanks again for digging into this.