GaCy-GO/docs/aa-round-sync.md

AA round selection sync — 2026-10-25

Confirmed path and defect

The Srtool AA dropdown posts peak_group_id to /api/monster-settings/aa-round; the SDK writes persistent.aa_round_selection. A read-only check returned group 2 with the configured Client version. The running Game executable contains the selection reader.

Before this change, the selected group affected only GetChallengePeakDataScRsp.CurrentPeakGroupId when the Client happened to request AA data. Saving from Srtool did not invalidate cached Client module state. StartChallengePeak continues to consume the actual requested PeakID; it does not consult the UI selector and must not silently substitute a different room.

The protocol's ChallengePeakGroupDataUpdateScNotify contains one ChallengePeakGroup, with no current-group field. Sending that notification is not proof that the selected current group changed. No numeric command alias or unsolicited response was added.

Source changes

• internal/gameserver/aa_round_sync.go builds a resource-validated desired group and selected-group/version digest. The default comes from the same loaded Peak groups as the data handler. It reads selection without writing saves.
• aa_round_sync.lua uses the actual current Client's ChallengePeakModule.SendGetChallengePeakDataRequest() and observes CurrentPeakGroupID. It sends one outstanding request and waits for the native value to match. It does not fabricate a response, alter private state, close a page, change scene, start a Battle, or remap a PeakID.
• Server gating defers while CURRENT_BATTLE, ChallengeRun, or CW is active; the Client also checks BattleGamePhase. Existing native login initialization (CurrentPeakGroupID == 0) is allowed to finish without issuing a duplicate request.
• GetChallengePeakData retains the existing Peak run's group until that run is left. It logs the actual selected group, number of groups and active-run state. Missing Peak resources now produce a typed error rather than a fabricated group/room list.
• Server README and Thai/English Srtool copy describe deferred native refresh rather than claiming that reopening the page necessarily causes a data request.

Evidence and validation boundaries

The current process metadata in Player.log, [GAC_AA_ROUND_META], reports:

UInt32 get_CurrentPeakGroupID()
Void SendGetChallengePeakDataRequest()

This evidence establishes the named native API, not its successful execution or UI refresh. Runtime pointers in the log are process-local and are not shipped or reused.

go build ./internal/gameserver and node --check ../GaC-srtool/js/i18n.js passed. No tests, save mutations, executable replacement, restart or Lua staging were performed for this source change. Root must wire loadAARoundRefreshLua(s) into heartbeat, build/deploy, and confirm the real request/reply plus [GAC_AA_ROUND_SYNC] applied and the displayed round before reporting Client success.

There is intentionally no timeout retry while an in-flight request cannot be distinguished from an unchanged result. A changed native group proves completion; new desired choices can then be requested. Reconnect/module replacement resets local request tracking. All activity schedules and resource room/boss definitions remain intact.