Repository navigation
Expand one generic registration over every protocol message with ManifestPrefix (F2) - #8536
Merged
Aaronontheweb merged 1 commit intoSep 11, 2026
Conversation
This was referenced Sep 9, 2026
Aaronontheweb
added this pull request to stack #8531
September 9, 2026 13:28
Aaronontheweb
force-pushed
the
feature/serialization-v2-expansion-adoption
branch
from
September 9, 2026 13:32
ac3376f to
f2f4e89
Compare
This was referenced Sep 9, 2026
Aaronontheweb
force-pushed
the
feature/serialization-v2-expansion-adoption
branch
from
September 9, 2026 17:15
f2f4e89 to
9cf2687
Compare
Aaronontheweb
force-pushed
the
feature/serialization-v2-expansion-adoption
branch
from
September 9, 2026 18:08
9cf2687 to
185decc
Compare
Aaronontheweb
force-pushed
the
feature/serialization-v2-expansion-adoption
branch
2 times, most recently
from
September 10, 2026 23:44
bfbdef8 to
f29d198
Compare
…ix; AKKASG034 retired (Decisions 17 and 18) Implements Decision 18 (closed-set expansion and adoption on the serializer) from openspec/changes/messagepack-sourcegen-validation/design.md: the ManifestPrefix property and its manifest-derivation formula, adoption of any AkkaSerializable type (generic or not) via a registration, the protocol-interface field as an implicit union, the one-owner rule (AKKASG041), and the construction-count info diagnostic (AKKASG042). AKKASG034 is retired; AKKASG020 stops rejecting a non-generic registration target. Decision 17 needed no code change (the generated union dispatch already throws on an unmatched runtime type or an unrecognized manifest). Adds round-trip, diagnostic, and golden-output test coverage; updates the user guide, the design record, and the task list.
Aaronontheweb
force-pushed
the
feature/serialization-v2-expansion-adoption
branch
from
September 11, 2026 15:05
f29d198 to
ccd44ba
Compare
Aaronontheweb
deleted the
feature/serialization-v2-expansion-adoption
branch
September 11, 2026 17:29
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes
One line registers a generic envelope for every message in a protocol, and the generator emits one concrete construction per member, all static:
This is the customer case from #8384. The rules are Decisions 17 and 18 in the design record and Decision C on the decision page.
ManifestPrefixon the registration attribute. The one public API change: a new init-only property onAkkaSerializableAttribute<TMessage>, extend-only.Manifestalone still registers exactly the named construction. Both together register the literal construction underManifestand the expansion under the prefix. Neither is the existing manifest-required error.Envelope<AcceptCassette>under prefixenvisenv/dmac.Pair<ICommsMessage, Envelope<AcceptCassette>>under prefixpair, with the inner construction registered asenv-dmac-v2, ispair/dmac/env-dmac-v2. An explicit registration for a construction wins over the derived name. AKKASG012 checks derived manifests for collisions like any other.[AkkaSerializable<T>]on a serializer now adopts any serializable type: a concrete type from this or a referenced assembly, or a construction. AKKASG020 no longer rejects non-generic targets. Every registration is a top-level message with a manifest, so a construction registered only for nested-field use now needs one too. The design text already said so. The golden corpus had one such registration; it gained a manifest, which is why three golden files and the resolved-serializer snapshot changed.[AkkaUnion]list.ManifestPrefixon a target with no closed set to expand, at the registration attribute. AKKASG041, error: a message owned by two serializers' closed sets, reported at both. AKKASG042, info: how many constructions an expansion produced. The design record and the decision page both say info with no threshold.ManifestPrefixwith the worked examples, the manifest rule, the implicit union, and the one-owner rule. The diagnostics table gains three ids and drops one.Known limit, for F3
The closed set behind an expansion is found by walking the compilation's types inside the serializer's per-keystroke step, once per prefix registration per edit. That is the shape S5 moved out of the coverage check. F3 moves that discovery into the facts stage. The benchmark corpus has no prefix registrations, so this cost does not show below.
Cost
Base is the F1 tip. Allocations measured twice, identical both times; means within noise. A first cut allocated 5 percent more on the rename row from an eager per-message builder in resolve, fixed with a cheap pre-check.
How it was checked
350 tests pass (334 plus 16: expansion end to end, expansion diagnostics, and two golden cases).
Akka.API.Tests: 18 pass; V2 has no approval file yet, so nothing to regenerate. V2, the generator, andAkka.Remotebuild with warnings as errors. cspell passes on the guide.BREAKING_CHANGES_V1.6.mdhas no V2 entries, so none was added.