test(net): guard that hidden-zone reveals reach the client delta - #11581
test(net): guard that hidden-zone reveals reach the client delta#11581shoeless wants to merge 2 commits into
Conversation
tool4ever
left a comment
tool4ever
left a comment
There was a problem hiding this comment.
imo seems too arbitrary to test that deltas would just start ignoring some zones...
besides NetworkChecksumUtil would quickly catch it anyway
e544c05 to
33b1276
Compare
…ent delta RevealSyncDeltaTest sets up an exact board with the AITest helpers (no AI, no sockets), grants a top-library reveal via Future Sight's continuous static, runs the real DeltaSyncManager.collectDeltas, and asserts the top card's PlayerMayLook travels in the delta the networked client receives. This guards the delta walker: DeltaSyncManager.walkAndCollect recurses into hidden zone (Library/Hand) collections and collects each nested CardView's dirty props, so an owner sees their own revealed top card without any extra zone flagging. No existing test covers this path — DeltaSyncUnitTest only checks packet byte-sizes, and NetworkPlayIntegrationTest checks public-zone visibility only (and is stress-gated). If a future change stopped walking hidden-zone collections, this fails; otherwise it is a fast (~10s), default-run regression guard, and a reusable pattern for "does host change X reach the client delta?". Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
I checked: Added a second commit that includes Library in the checksum walk so runtime does catch it — feel free to drop that commit if it's unwanted, and equally fine closing the test if you'd rather rely on the checksum alone. @MostCromulent — was leaving Library out of the checksum walk deliberate (perf/scope), or just not needed at the time? |
33b1276 to
55594f6
Compare
collectChecksumObjects walked Battlefield/Hand/Graveyard/Exile/Command but not Library, so hidden-zone card state (e.g. a PlayerMayLook reveal from Future Sight-style effects) could desync silently — no checksum ever saw it. Add Library to the walk; the collection hash is order-insensitive (sorted ids) and the cost is a few hundred extra property hashes per sampled checksum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
55594f6 to
5c6b7d4
Compare
I'm pretty sure this was just an oversight rather than a deliberate design choice. |
|
focus was on public zones since walking libraries with little dynamic properties seems rather pointless |
3 participants
What
Adds
RevealSyncDeltaTest— a deterministic, in-process regression test that verifies a hidden-zone card reveal reaches a networked client through the real delta-sync path.The test:
AITesthelpers (no AI, no sockets, ~10s).MayLookAt$ Playerstatic reveals the top card (verified againstCardView.canBeShownTo).DeltaSyncManager.collectDeltasand asserts the top card'sPlayerMayLookis present in the delta the client receives.Why
DeltaSyncManager.walkAndCollectrecurses into hidden-zone (Library/Hand)TrackableCollectionproperties and collects each nestedCardView's dirty props — which is what lets a player see their own revealed top card (Future Sight, Garruk's Horde, etc.) on a networked client. That behavior was not covered by any existing test:DeltaSyncUnitTestonly checksDeltaPacketbyte-size accounting — it never runscollectDeltason a realGameView.NetworkPlayIntegrationTestchecks visibility for public zones only (Battlefield/Graveyard/Exile) and is stress-gated / non-deterministic.If a future change stopped walking hidden-zone collections, the owning player would silently stop seeing their own revealed top card — this test would catch it. It also documents a reusable pattern for "does host change X reach the client delta?" tests.
Test-only change; no engine/runtime code touched.
🤖 Generated with Claude Code