[CRITICAL] Fallbacks are mutable during traversal

[Aaronontheweb]

Version: v1.3.1

Reproduction: #192

[Fact]
        public void Should_dump_HOCON_with_2_Fallback()
        {
            var myHocon1 = ConfigurationFactory.ParseString(@"akka{
                actor.provider = cluster
                deployment{
                    /foo {
                        dispatcher = bar
                    }
                }
            }");

            var myHocon2 = ConfigurationFactory.ParseString(@"akka{
                debug{
                    received  = on
                }
                actor.provider = cluster
                deployment{
                    /foo {
                        dispatcher = foo
                    }
                    /bar {
                        mailbox = ""myFoo""
                    }
                }
            }");

            var myHocon3 = ConfigurationFactory.ParseString(@"akka{
                remote{
                    transport = ""foo""
                }
            }");

            var fullHocon = myHocon1
                .SafeWithFallback(myHocon2)
                .SafeWithFallback(myHocon3);

            // bug reproduction
            //fullHocon.GetString("akka.remote.transport").Should().Be("foo");

            var dump = fullHocon.DumpConfig();
            dump.Should().Contain(myHocon1.PrettyPrint(2));
            dump.Should().Contain(myHocon2.PrettyPrint(2));
            dump.Should().Contain(myHocon3.PrettyPrint(2));
        }
    }

If I run this test, as-is, all of the text for each fallback will be correctly preserved and the test will pass and produce the following output:

HOCON0
{
  akka : {
    actor : {
      provider : cluster
    },
    deployment : {
      /foo : {
        dispatcher : bar
      }
    }
  }
}

------------
HOCON1
{
  akka : {
    debug : {
      received : on
    },
    actor : {
      provider : cluster
    },
    deployment : {
      /foo : {
        dispatcher : foo
      },
      /bar : {
        mailbox : "myFoo"
      }
    }
  }
}

------------
HOCON2
{
  akka : {
    remote : {
      transport : "foo"
    }
  }
}

This is the expected output.

However, if I uncomment the fullHocon.GetString("akka.remote.transport").Should().Be("foo") line... Here is what we end up with instead:

HOCON0
{
  akka : {
    actor : {
      provider : cluster
    },
    deployment : {
      /foo : {
        dispatcher : bar
      }
    }
  }
}

------------
HOCON1
{
  akka : {
    debug : {
      received : on
    },
    actor : {
      provider : cluster
    },
    deployment : {
      /foo : {
        dispatcher : bar
      },
      /bar : {
        mailbox : "myFoo"
      }
    }
  }
}

------------
HOCON2
{
  akka : {
    remote : {
      transport : "foo"
    },
    debug : {
      received : on
    },
    actor : {
      provider : cluster
    },
    deployment : {
      /foo : {
        dispatcher : bar
      },
      /bar : {
        mailbox : "myFoo"
      }
    }
  }
}

The test fails in this scenario because the fallback HOCON values are populated with the values from the head.

In other words, with the following HOCON chain:

hocon1 --> fallback1 --> fallback2

When I call hocon1.ToString("keyInFallback2") all of the values from hocon1 will be mapped onto fallback1 and all of the values from fallback1 will be mapped onto fallback2. As a result, we can have race conditions and all sorts of other weird errors in the Akka.NET test suite.

This aligns with exactly the bugs I'm trying to track down in akkadotnet/akka.net#4128

[Aaronontheweb]

Adding the text files from above:

hocon-correct.txt
hocon-bad.txt

[IgorFedchenko]

Wondering why this tests is passing...
Because using

var _ = fullHocon.Root.GetObject();

instead of

fullHocon.GetString("akka.remote.transport").Should().Be("foo");

also makes spec to fail.

So I thought that I have already fixed this, and added test for it. Will check what is the difference.

[IgorFedchenko]

And even more interesting:

myHocon2.GetString("akka.deployment./foo.dispatcher").Should().Be("foo");

passes.

@Aaronontheweb Ah, got it.
So yes, Fallback objects, that are stored in config, are modified (merged with initial config value) - that's why they are cloned from original fallback objects when saved to Fallback property.
So original myHocon2 is cloned, and stays unmodified, while inner Fallback of myHocon1 object is modified.

This was by design, did not thought that this can be an issue. But it is easy to fix, I will submit PR right now