Optional scalapb serialization binding breaks existing mapping

Akka Libraries Actors
1

Hi there,
related to this feature in 2.9.0 release: feat: Optionally include serialization binding for ScalaPb by patriknw · Pull Request #32070 · akka/akka · GitHub

I see that starting from akka 2.9.0, an optional serialization binding is added to the reference.conf which maps all scalapb generated classes to the akka ‘proto’ serializer and this version breaks our application since we also use scalapb and also have another serializer defined for the classes that extend from a specific tagging trait we’ve created.

For some reason I think the sorting logic is broken since 2.9.0, I started to see “Multiple serializers found” warnings, apparently akka finds 2 different serializers, first one being the akka default proto serializer, and that one is picked which is not correct.

our generated classes have a signature like this: “final case class Initialized() extends scalapb.GeneratedMessage with scalapb.lenses.Updatable[Initialized] with com.ing.baker.runtime.akka.actor.serialization.BakerSerializable”

and we have this config in our reference conf: "com.ing.baker.runtime.akka.actor.serialization.BakerSerializable" = baker-typed-protobuf

To fix this issue I either need to bind scalapb.GeneratedMessage to ‘none’ or ‘baker-typed-protobuf’, so that akka doesn’t pick its default serializer.

Do you think that this is a regression introduced with akka 2.9.0? or a misconfiguration?

Thanks in advance.

2

Akka will pick the most specific serializer found, but I guess since your generated messages extend both BakerSerializable and GeneratedMessage none of them are more specific, so the ambiguity and warning is expected.

I think it should be fine to bind GeneratedMessage to none since that is meant for convenience. None of the internal protobuf messages in akka-remoting or cluster is using ScalaPB.

I’m not 100% sure I remember correctly, but think it was added specifically for when using akka-projection-grpc or replicated event sourcing over gRPC in a Scala project.

3

Thanks Johan, for the time being, mapping scalapb.Generated to none solves our issue hoping that scalapb generated classes are not used internally by akka. I think mapping them to none will break internal messaging if they’ll ever be used by akka later.
What could be a better binding design in the bindings is to be able to group multiple classes, traits into one binding to help akka decide in the sorting logic to pick the most specific configuration. I don’t know if possible by design, but something like this as a suggestion:

akka.actor.serialization-bindings {
  ["com.ing.baker.runtime.akka.actor.serialization.BakerSerializable", "scalapb.GeneratedMessage"] = baker-typed-protobuf
  "scalapb.GeneratedMessage" = proto
}