IndexOutOfRangeException in StringEncodedWriteVector.FlipBit

[Liversage]

I have tried to upgrade my project from 1.3.1 to 1.4.0. However, I'm currently having problems with IndexOutOfRangeException being thrown by StringEncodedWriteVector.FlipBit. This happens because both writeVector and Replica are empty strings thus pos = writeVector.IndexOf(Replica) becomes 0 and then writeVector[pos - 1] throws the exception.

Eventually, the exception is caught in PrimaryBasedLogViewAdaptor.UpdatePrimary where the comment states the following:

this should never happen - we are supposed to catch and store exceptions
in the correct place (LastPrimaryException or notification trackers)

Obviously, there is something wrong in my code. However, it seems that whatever is wrong triggers some unexpected errors in Orleans that are hard to understand.

While I came here to report the unexpected way that FlipBit can fail when passed two empty strings any suggestions why this happens in the first place are welcome. I have modified my code based on the updated documentation on event sourced grains and it is not obvious to me what I'm doing wrong. One thing that is a bit special is that this error happens during silo startup where a bootstrap provider calls some event sourced grains.

[sergeybykov]

I hope @sebastianburckhardt knows what might be going on here.

[sebastianburckhardt]

The Replica is never supposed to be null. It is initialized from the Silo.ClusterId which is currently determined as follows:

public string ClusterId
{
   get { return GlobalConfig.HasMultiClusterNetwork ? GlobalConfig.ClusterId : GlobalConfig.DeploymentId; } 
}

.
So the likely root cause is that GlobalConfig.DeploymentId is null for some reason (or GlobalConfig.ClusterId if you are using the multi-cluster network). Not sure how that can happen... I thought this is being checked somewhere.

Maybe your configuration is not setting the DeploymentId?

(Regardless, we obviously need a better error message). Thanks for looking into this.

[Liversage]

I am encountering this problem during development where I run a single silo essentially configured as described in the Local Development section of the Typical Configurations documentation page.

DeploymentId is not set by this configuration and this has not been a problem in 1.3.1. I guess that if I add the value to the development configuration I would be able to work around the issue in 1.4.0.

[sebastianburckhardt]

Yes, as a workaround, try to set the DeploymentId to something other than null or empty.

I don't think it matters what you pick, e.g. "A".

We will fix this so the code to automatically pick a default if DeploymentId is null or empty.

[sergeybykov]

Fixed via #2786.