Leaderboard

[patchzyy]

Summary by CodeRabbit

• New Features
  • Added new Leaderboard page displaying top 50 ranked players with podium-style visualization.
  • Integrated friend detection to show which players are your friends.
  • Added online status indicators across rooms and leaderboards.
  • Added join room functionality via button in player listings.
  • Improved API performance with response caching.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch Leaderboard

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@WheelWizard/Features/RrRooms/RrLeaderboardSingletonService.cs`:
- Around line 77-90: The TryGetAnyCache method currently bails out if
_cachedEntries.Count < limit; instead, when the API fails and the cache is
smaller than the requested limit we should return the available stale entries
with a warning rather than false. Change TryGetAnyCache so that inside the lock
it always constructs an OperationResult<List<RwfcLeaderboardEntry>> from
TrimToLimit(_cachedEntries, _cachedEntries.Count) (or TrimToLimit with
min(limit, _cachedEntries.Count)) and mark that OperationResult as a
warning/partial result (or log a warning) when Count < limit, returning true;
keep the existing success path when count >= limit. Use the existing
OperationResult wrapper semantics so callers can detect partial/stale data.
- Line 28: The call to await _refreshGate.WaitAsync() in
RrLeaderboardSingletonService should use a timeout to avoid indefinite blocking;
replace it with an awaited timed wait (e.g. await
_refreshGate.WaitAsync(TimeSpan.FromSeconds(<reasonableTimeout>))) or use a
CancellationToken with a timeout, check the boolean result and handle the
timeout path (log/throw or return) if acquisition fails, and ensure you still
release the semaphore via _refreshGate.Release() only when acquired; update any
surrounding try/finally to account for the possible non-acquired case.

In `@WheelWizard/Views/Layout.axaml`:
- Around line 137-139: Replace the hardcoded "Leaderboard" string on the
SidebarRadioButton with a localized resource reference and add the corresponding
key to the language resource files; specifically update the SidebarRadioButton
that has IconData="{StaticResource Award}" and PageType="{x:Type
pages:LeaderboardPage}" to use Text="{x:Static
lang:Common.PageTitle_Leaderboard}" (or the equivalent resource lookup used
elsewhere) and then add PageTitle_Leaderboard to the lang Common resource files
for each locale with the translated values.

In `@WheelWizard/Views/Pages/LeaderboardPage.axaml`:
- Around line 83-97: The hard-coded user strings in the XAML need to be moved to
the app's language resource set and referenced from the controls: replace
Text="Leaderboard" on the TextBlock and TipText="Top 50 players" on
components:StateBox with resource lookups (e.g. StaticResource/DynamicResource
or your existing localization markup extension) using new keys like
"Leaderboard_Title" and "Leaderboard_Top50Players", add those keys and
translated values to the language resource file(s), and ensure the XAML
references those keys (keeping TotalPlayerCountText binding unchanged).