Hello,
It seems that generic grains can never have their state loaded properly on activation, as the various PlacementDirectors that produce the grainType string to be used in retrieving the grain from storage are all without generic type information for the grain in question, and therefore produce grainTypes with generic args missing.
This contrasts with explicitly calling ReadStateAsync() and WriteStateAsync() from the grain itself, which, via GrainStateStorageBridge, produces a fully-specified grainType each time.
The upshot is, state is written to one storage key, but loaded from another in the case of activation.
There's a simple enough workaround in calling ReadStateAsync() from each generic grain's OnActivateAsync() - but this isn't fantastic, obviously.
Does this sound right?
Hello,
It seems that generic grains can never have their state loaded properly on activation, as the various
PlacementDirectorsthat produce thegrainTypestring to be used in retrieving the grain from storage are all without generic type information for the grain in question, and therefore producegrainTypeswith generic args missing.This contrasts with explicitly calling
ReadStateAsync()andWriteStateAsync()from the grain itself, which, viaGrainStateStorageBridge, produces a fully-specifiedgrainTypeeach time.The upshot is, state is written to one storage key, but loaded from another in the case of activation.
There's a simple enough workaround in calling
ReadStateAsync()from each generic grain'sOnActivateAsync()- but this isn't fantastic, obviously.Does this sound right?