Serialization: built-in serializers declare their ids in code (#8676, part 1)

[Aaronontheweb]

Purpose

Part 1 of the plan to move first-party serializer registration into C# (#8676). Every built-in legacy serializer now declares its wire id in code with public override int Identifier => N; (or a GetType()-guarded version of it, see below), instead of reading it lazily from akka.actor.serialization-identifiers via SerializerIdentifierHelper.GetSerializerIdentifierFromConfig. That HOCON lookup is lazy on first access to Identifier - it is never called from the Serializer constructor - so nothing about serializer construction changes. No wire bytes change: every id below is exactly what each module's .conf already ships.

Serializers and ids

• Remote: ProtobufSerializer 2, DaemonMsgCreateSerializer 3, MessageContainerSerializer 6, MiscMessageSerializer 16, PrimitiveSerializers 17, SystemMessageSerializer 22
• Cluster: ClusterMessageSerializer 5, ReliableDeliverySerializer 36 (internal)
• Cluster.Tools: DistributedPubSubMessageSerializer 9, ClusterSingletonMessageSerializer 14, ClusterClientMessageSerializer 15
• Cluster.Sharding: ClusterShardingMessageSerializer 13
• DistributedData: ReplicatedDataSerializer 11, ReplicatorMessageSerializer 12
• Cluster.Metrics: ClusterMetricsMessageSerializer 10
• Persistence: PersistenceMessageSerializer 7, PersistenceSnapshotSerializer 8
• Streams: StreamRefSerializer 30
• Core: ByteArraySerializer 4, NewtonSoftJsonSerializer 1

NullSerializer already overrode Identifier, so it's untouched. ArteryControlMessageSerializer is skipped: its id already comes from the [AkkaSerializer<T>] V2 source-generator attribute, not from HOCON. Hyperion (src/contrib/serializers) is a third-party serializer and is out of scope; it stays on HOCON/SerializationSetup.

The GetType() guard on public, unsealed serializers

Serializer.Identifier resolves by GetType(), not by the declaring type. A plain public override int Identifier => N; on a serializer that a user can subclass would report N for the subclass too, even if the subclass is registered under its own HOCON id - silently taking over GetSerializerById(N) for messages the subclass never wrote. So every serializer that is public and unsealed guards the constant on an exact type check and falls back to the base (HOCON) lookup otherwise:

public override int Identifier => GetType() == typeof(ProtobufSerializer) ? 2 : base.Identifier;

The 12 affected classes: ProtobufSerializer, DaemonMsgCreateSerializer, MessageContainerSerializer, ClusterMessageSerializer, DistributedPubSubMessageSerializer, ClusterSingletonMessageSerializer, ClusterClientMessageSerializer, ClusterShardingMessageSerializer, ClusterMetricsMessageSerializer, PersistenceSnapshotSerializer, ByteArraySerializer, NewtonSoftJsonSerializer.

The other 8 (MiscMessageSerializer, PrimitiveSerializers, SystemMessageSerializer, ReplicatedDataSerializer, ReplicatorMessageSerializer, PersistenceMessageSerializer, StreamRefSerializer - all sealed - and ReliableDeliverySerializer, which is internal sealed) can't be subclassed, so they keep a plain constant.

No wire change

Ids come from code now but are identical to what HOCON already assigned. Existing serialization and remote round-trip specs pass unchanged.

Breaking changes

A built-in serializer's id can no longer be overridden via akka.actor.serialization-identifiers. Before this change, an application that set, for example, "Akka.Remote.Serialization.MiscMessageSerializer, Akka.Remote" = 99 in its own HOCON would make that node write id 99 on the wire. Now the code id (16, in that example) always wins, because it's a hardcoded Identifier override rather than a config lookup. A user subclass of a built-in serializer keeps resolving its own id from HOCON - only the built-in type itself is pinned.

• Migration: ids of built-in serializers are wire contracts and can no longer be overridden. Remove any serialization-identifiers override of a built-in Akka.NET serializer from your HOCON; it no longer has any effect.

This is expected to affect very few, if any, real applications, since overriding a built-in serializer's id would already have broken wire compatibility with any node that didn't carry the same override.

Tests

• One [Fact] in Akka.API.Tests - the only project that references all 9 affected modules (Remote, Cluster, Cluster.Tools, Cluster.Sharding, DistributedData, Cluster.Metrics, Persistence, Streams, core) - merges every module's default config and, for every row in akka.actor.serialization-identifiers, builds the serializer with RuntimeHelpers.GetUninitializedObject (skipping the constructor, leaving the actor-system field null) and asserts Identifier matches the row. A serializer whose id still resolved lazily from HOCON would touch that null field and throw, so this test also proves D1 for every built-in serializer in one place.
• One regression spec in Akka.Tests: a NewtonSoftJsonSerializer subclass registered under its own HOCON id keeps that id, and the built-in NewtonSoftJsonSerializer still reports 1.
• Ran the full Serialization-filtered tests in Akka.Tests, Akka.Remote.Tests, Akka.Cluster.Tests, Akka.Persistence.Tests and Akka.Streams.Tests (all green), plus the serializer specs in Akka.Cluster.Tools.Tests, Akka.Cluster.Sharding.Tests, Akka.DistributedData.Tests and Akka.Cluster.Metrics.Tests.
• dotnet test src/core/Akka.API.Tests -c Release -f net10.0: adding the Identifier overrides changes the public API surface for 9 assemblies (the property signature is unchanged, only its body), so both the DotNet and Net approval files were updated with just the added Identifier override lines.

Next steps

PR 2 moves alias and binding registration into the modules' ModuleSerializers tables, so the C# tables carry everything HOCON carries today (behavior unchanged, verified by parity specs). Later PRs load those tables from code and delete the built-in HOCON rows.

[Aaronontheweb]

LLGTM