GetWeeklyActivenessRewardRequest implementation

[Hexaflare]

Support GetWeeklyActivenessRewardRequest

Problem

The game server logged an unhandled request on login/task-panel use:

[WARN]: Request handler not found: name="GetWeeklyActivenessRewardRequest", nameLength=32, contentBytes=1, id=273

The client calls this with an empty body {} when the player claims Weekly (WeeklyTwo) activeness rewards. No handler was registered, so the reward was never granted.

What the request is

• Client call: XTaskManager:GetWeeklyActivenessRewardRequest (XTaskManager.lua:782).
• Response fields the client reads: Code, RewardGoodsList, WeeklyTaskActivenessProgress.
• WeeklyTaskActivenessProgress is the full set of activeness milestone values already claimed this week (the client replaces its local cache with this list).
• The track is CurrentTaskActivenessTable.Type == 5 (CurrentTaskActiveness.tsv): milestones [5, 10], rewards [68860, 68870].
• Activeness is not an item: the client derives it from finished tasks tagged Weekly in Task.tab (XTaskManager.GetWeeklyTaskActiveness, XTaskManager.lua:1700). Server-side equivalent is the count of (ClaimedTaskIds ∪ stage.FinishedTasks) whose TaskTable.Tag == 1.
• Rewards 68860/68870 resolve through the normal Reward.tab (688600/688700 → item 106 "Makeup Sign-in Card"), not CurrentReward.tab, so this path uses RewardHandler.GetRewardGoods.

Implementation

• Added GetWeeklyActivenessRewardResponse { Code, RewardGoodsList, WeeklyTaskActivenessProgress }.
• Registered [RequestPacketHandler("GetWeeklyActivenessRewardRequest")]; the body is empty and ignored.
• Activeness is counted from the authoritative task tables and persisted player/session state (no hardcoded values).
• Claims use the repo's current idempotency convention: RewardHandler.ApplyRewardsOnceAndPersist with a week-scoped claim key weekly-two:{week}:{milestone} stored in AppliedRewardClaims (mirrors current-task:{taskId}:{week}). No new persisted DB field.
• WeeklyTaskActivenessProgress is derived by scanning the current week's claim keys.
• Weekly rollover naturally re-enables claims because the key embeds MissionProgress.WeeklyResetWeek.
• Populated NotifyTaskData.TaskData.WeeklyTaskActivenessProgress at login so claimed checkmarks survive relog (the client already reads data.TaskData.WeeklyTaskActivenessProgress, XTaskManager.lua:370).
• Error codes reuse the existing activeness family: 20026010 (not reached / config or reward missing), 20026012 (already claimed), 20026003 (persist failure). Success is 0.

Files changed

File	Change
AscNet.GameServer/Handlers/TaskModule.cs	Response DTO, WeeklyTaggedTaskIds, GetWeeklyActivenessRewardRequest handler, ClaimWeeklyTwoRewards / BuildWeeklyTwoProgress / claim-key helpers
AscNet.Common/MsgPack/Types.cs	WeeklyTaskActivenessProgress on NotifyTaskDataTaskData
AscNet.GameServer/Handlers/AccountModule.cs	Populate WeeklyTaskActivenessProgress at login
AscNet.Test/Program.cs	ValidateWeeklyActivenessRewardCompatibility (wired into ValidateLoginAccountCompatibility) + --weekly-activeness-compat-only switch

Verification

Builds clean (0 warnings / 0 errors) for AscNet.Common, AscNet.GameServer, AscNet.Test.

Focused harness (dotnet run --project AscNet.Test/AscNet.Test.csproj -- --weekly-activeness-compat-only, exit 0):

Claimed tagged tasks	Result
4	Code = 20026010, no rewards
5	Code = 0, reward 688600, progress [5]
10	Code = 0, reward 688700, progress [5, 10]
repeat	Code = 20026012, no rewards

--login-account-compat-only passes (exit 0), confirming the login payload addition does not regress login shape or startup push order.

Known unrelated failure

The full default harness stops at a pre-existing failure in ValidateBossSingleCompatibility:

Pain Cage rollover archives stage best: expected 'True', got 'False'

Reproduced with the login field temporarily removed, so it is unrelated to this change (and aborts the harness before later validations run).

AGENTS.MD compliance

• No hardcoded protocol data: activeness, milestones, reward IDs, and the tagged-task set are read from authoritative tables (CurrentTaskActiveness.tsv, Reward.tsv, Task.tsv); claim state comes from persisted AppliedRewardClaims. No captured payloads, retail IDs, balances, or timestamps are embedded. Type == 5 and Tag == 1 are table semantics (same style as the existing x.Type == 3/4 checks), and the error codes reuse existing server protocol values.
• Tables authoritative: no TSV or generated table source was hand-edited.
• DTOs: GetWeeklyActivenessRewardResponse uses the named-key [MessagePackObject(true)] pattern, co-located with the sibling task DTOs per the module's existing convention; the shared/persisted login schema change lives in AscNet.Common/MsgPack/Types.cs as AGENTS prescribes.
• Handler mechanics: [RequestPacketHandler("GetWeeklyActivenessRewardRequest")], response sent with the request's packet.Id. The request body is empty ({}), so no request DTO is deserialized — consistent with GetNewbieRewardRequestHandler / GetNewbieHonorRewardRequestHandler.
• Persistence: grants go through RewardHandler.ApplyRewardsOnceAndPersist, which saves inventory/character with rollback on failure.
• Testing: narrow --weekly-activeness-compat-only first, then the full harness; derived fields covered with distinct states (4 / 5 / 10). The one full-harness failure is pre-existing and unrelated (see above).
• No captures / artifacts: no packet captures, .runtime/, bin/, obj/, or runtime logs added.

Notes / follow-ups

• Week-scoped claim keys accumulate (~2/week) and are not pruned, consistent with existing current-task: keys.
• InvalidDataException/error handling and reward rollback are delegated to RewardHandler.ApplyRewardsOnceAndPersist.

[reiserFSs]

Reviewed c956332. Changes requested before merge.

1. Hydrate previously claimed weekly tasks into login FinishedTasks. WeeklyTwoActiveness counts MissionProgress.ClaimedTaskIds, but AccountModule.cs:1318 sends only session.stage.FinishedTasks and EN XTaskManager.GetWeeklyTaskActiveness counts the client's FinishedTasks map. Real FinishTask handlers claimed30039-30042, BSON relog produced NotifyTaskData.FinishedTasks=[], then task30043 gave visible count1 versus server count5; direct weekly RPC returnedCode0/progress[5], while the normal UI cannot issue it. Include persisted claimed weekly tasks in the login projection and add a claim/relog/further-claim regression. Relevant new code TaskModule.cs:492-496.

2. Exclude previous-week GuildWeekly completions after rollover. WeeklyTaggedTaskIds includes Type23 GuildWeekly tasks, but EnsureMissionResets clears only CurrentTask Type3 claims. A valid persisted prior-week task3001728 survived reset; four current-week completions then incorrectly granted the five-task milestone. Reset all refreshable weekly-tag claims consistently, preserving unrelated lifetime tasks, and cover prior-week guild claims plus current-week threshold boundaries. Relevant TaskModule.cs:149-151 and weekly reset implementation.

Verification note: Release build and --weekly-activeness-compat-only pass, but external real-handler/BSON relog and rollover probes reproduced these cases; full harness stops at the known pre-existing Pain Cage rollover assertion. No native UI execution claimed.

[Hexaflare]

Two review findings, reproduced by external probes, are fixed here.

1. Persisted weekly claims missing from the login projection

BuildNotifyTaskData sent FinishedTasks = session.stage.FinishedTasks (story tasks only), but client XTaskManager.InitTaskData seeds its FinishedTasks map only from that field, and GetWeeklyTaskActiveness counts that map. After a BSON relog the client saw activeness 1 while the server saw 5, so the reward grid stayed inactive and the normal UI could not issue the RPC. Fixed by projecting persisted claimed weekly-tag tasks (TaskModule.WeeklyTwoClaimedTaskIds) into NotifyTaskData.TaskData.FinishedTasks.

2. Prior-week GuildWeekly (Type 23) claims survived rollover

WeeklyTaggedTaskIds includes Type 23 guild-weekly tasks that are not present in CurrentTask.tsv, so ResetMissionType(session, 3) cannot clear them. A persisted prior-week 3001728 claim survived the weekly reset and, with four current-week completions, incorrectly reached the five-task milestone. Fixed by clearing all weekly-tag claims on weekly rollover (TaskModule.ResetWeeklyTagClaims), while preserving condition counters shared with unrelated tasks (e.g. 35010, also used by the Type 6 Thursday-reset task).

Differential verification

• New regressions ValidateWeeklyActivenessLoginProjectionCompatibility (claim → BSON relog → further claim) and ValidateWeeklyActivenessRolloverCompatibility (prior-week guild claim + current-week 4/5 threshold) run under --weekly-activeness-compat-only and are DB-isolated via MongoCollectionOverride.InstallForWeeklyActivenessCompatibility.
• With the two runtime fixes temporarily reverted, the same test code fails: Weekly activeness login projection contains claimed task 30039: expected 'True', got 'False' and Weekly activeness rollover clears prior-week GuildWeekly claim: expected 'False', got 'True'. Restored, both pass.
• dotnet build -c Release + --weekly-activeness-compat-only: pass (exit 0).
• --login-account-compat-only passes (exit 0) against the local MongoDB, and the full harness (Release) reaches and passes the new weekly regressions, stopping only at the pre-existing Pain Cage rollover assertion.

[reiserFSs]

Changes requested: three verified weekly lifecycle defects remain.

1. P1 — Weekly rollover reuses lifetime guild reward receipts (AscNet.GameServer/Handlers/TaskModule.cs:2448–2452). Three real guild-stage first uploads reach condition 35010=3 and allow task 3001728 to grant rewards. After persisting a stale week and running the real login routine, the claimed-task marker is cleared, but progress and guild-achievement:3001728 receipts remain. A second FinishTaskRequest returns Code 0 and two reward entries with zero inventory delta, then counts the task as finished in the new week. Scope Type-23 progress and claim receipts to the weekly period without incorrectly resetting the shared Type-6 progress.

2. P2 — One receipt blocks recovery of a partial reward save (TaskModule.cs:505–507). Injecting character-save failure after inventory persistence returns 20026003 and leaves an inventory-only receipt. After durable BSON reload, retry returns 20026012 with no pushes and never repairs the missing character receipt. Only a fully completed grant should exclude the milestone; allow the existing receipt-aware grant helper to finish partial saves without duplicate rewards.

3. P2 — Login materializes stale FinishedTasks before reset (AscNet.GameServer/Handlers/AccountModule.cs:832–839). With old-week historical task 35011 and no guild membership, the actual login routine sends that ID in NotifyTaskData.FinishedTasks even though persisted state has removed it. Reconcile the weekly period before materializing any login task projection.

Verification: registered handlers, three real guild-stage uploads, actual login routine against isolated MongoDB, and durable BSON plus injected-save-failure checks. Existing weekly/login selectors pass but do not defend these boundaries.