erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions

fix(net,runtime): FA2 fix-round MUST-FIX -- allegiance clears at reset, 0x027C stops seeding

Browse source 
Two MUST-FIX findings from the FA2 mechanism/blast reviews
(docs/research/2026-08-12-fa2-review-mechanism.md,
docs/research/2026-08-12-fa2-review-blast.md):

MF-1 (mechanism) -- RuntimeAllegianceState survived a generation reset,
contradicting retail (ClientAllegianceSystem::OnEndCharacterSession
@0x00569FA0 tail-calls AllegianceProfile::Clear at the same boundary
Fellowship already clears at), contradicting the precedent it cited
(RuntimeCharacterOptionsState.ResetSession clears-and-relatches, it does
not persist), and pinned by a test asserting the wrong behavior. Fixed:
RuntimeAllegianceState.ResetSession() clears the profile and drops
HasServerSeed; a new RuntimeGenerationResetStage.Allegiance stage runs it
on every generation reset, mirroring RuntimeFellowshipState exactly.
RuntimeGenerationResetTests' FellowshipClearsAtResetButAllegianceSurvivesReconnect
inverted to FellowshipAndAllegianceBothClearAtGenerationReset.

MF-2 (mechanism) / blast MF-2 -- 0x027C AllegianceInfoResponse fed the
Runtime allegiance owner (self-gated). Retail's own handler for 0x027C
(CM_Allegiance::DispatchUI_AllegianceInfoResponseEvent @0x006a7470) unpacks
into a stack-local profile destroyed on return; the consumer
(Handle_Allegiance__AllegianceInfoResponseEvent @0x0056a1d0) only prints
AddTextToScroll lines. Retail's panel is fed exclusively by 0x0020
AllegianceUpdate. The removed seeding also fabricated
RuntimeAllegianceSnapshot.Rank (0x027C carries no rank field) on any
client whose first allegiance message was a self @allegiance info query.
Fixed: dropped ApplyInfoResponseSelf, the onAllegianceInfoResponseSelf
delegate hole, and the self-gate; 0x027C is text-only again, matching
retail and the pre-FA2 shape.

Also covers blast SHOULD-FIX 1 in the same edit to LiveSessionEventRouter.cs:
the fellowship/allegiance delegate holes are now passed conditionally on
the owner being supplied, so GameEventDispatcher.GetUnhandledCount reads
correctly for callers without an owner (bare-ChatLog tests, a future
partial host) instead of silently reading 0 for 9 event types whose parse
result was discarded.

RuntimeAllegianceState.cs and the two owners' Apply* mutators also move
their ObjectDisposedException.ThrowIf checks inside the lock they already
take (mechanism SHOULD-FIX 2) -- the prior check-then-lock shape let an
inbound event on the decode thread race Dispose on the host thread and
repopulate state after _disposed = true, permanently falsifying
CaptureOwnership().IsConverged at teardown.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-12 02:17:04 +02:00
parent 63649c8053
commit 4272ad0ea4
9 changed files with 425 additions and 229 deletions
Download patch file Download diff file Expand all files Collapse all files

29
tests/AcDream.Runtime.Tests/RuntimeGenerationResetTests.cs
View file

@ -200,13 +200,20 @@ public sealed class RuntimeGenerationResetTests
}
[Fact]
public void FellowshipClearsAtResetButAllegianceSurvivesReconnect()
public void FellowshipAndAllegianceBothClearAtGenerationReset()
{
// Campaign FA slice FA2 (2026-08-12), D2: fellowship is
// session-scoped (cleared at every generation reset, matching the
// ExternalContainer precedent); allegiance is NOT a reset stage at
// all — it survives reconnect exactly like a real disconnect does
// not sever your character's allegiance membership.
// Campaign FA slice FA2 (2026-08-12), D2, CORRECTED by the FA2
// fix-round MUST-FIX 1 (2026-08-12,
// docs/research/2026-08-12-fa2-review-mechanism.md): this test
// previously asserted the opposite of retail's behavior —
// "allegiance survives reconnect". Retail's
// ClientAllegianceSystem::OnEndCharacterSession @0x00569FA0
// tail-calls AllegianceProfile::Clear at exactly this boundary,
// mirroring the sibling ClientFellowshipSystem::
// OnEndCharacterSession @0x005690A0 fellowship already honored, and
// the cited precedent (RuntimeCharacterOptionsState.ResetSession)
// CLEARS and re-latches, it does not persist. Both owners are now
// RuntimeGenerationReset stages and both clear here.
using var runtime = Create();
runtime.PlayerIdentity.ServerGuid = 0x50000001u;
runtime.FellowshipOwner.ApplyFullUpdate(new GameEvents.FellowshipFullUpdate(
@ -231,16 +238,18 @@ public sealed class RuntimeGenerationResetTests
Assert.True(runtime.Fellowship.Snapshot.IsInFellowship);
Assert.True(runtime.Allegiance.Snapshot.HasProfile);
Assert.True(runtime.AllegianceOwner.HasServerSeed);
var host = new RecordingResetHost(runtime);
runtime.ResetGeneration(new RuntimeGenerationToken(3), host);
Assert.False(runtime.Fellowship.Snapshot.IsInFellowship);
Assert.Equal(0, runtime.Fellowship.Snapshot.MemberCount);
// Allegiance is untouched by the reset — the data survives.
Assert.True(runtime.Allegiance.Snapshot.HasProfile);
Assert.True(runtime.AllegianceOwner.HasServerSeed);
Assert.Equal("The Order", runtime.Allegiance.Snapshot.AllegianceName);
Assert.False(runtime.Allegiance.Snapshot.HasProfile);
Assert.False(runtime.AllegianceOwner.HasServerSeed);
Assert.Equal(string.Empty, runtime.Allegiance.Snapshot.AllegianceName);
Assert.Equal(0u, runtime.Allegiance.Snapshot.MonarchGuid);
Assert.Equal(0, runtime.Allegiance.Snapshot.RecordCount);
}
private static GameRuntime Create()