Fix stale rating range in custom game seek

[EishaEnan]

Problem

When creating a custom challenge with a rating range (e.g. 0 → +500), the range is calculated based on the user's rating at the time of setup.

However, after finishing a game and gaining or losing rating, creating a new seek reuses the old rating range instead of recalculating it based on the updated rating.

This leads to inconsistent matchmaking behavior:

• Example:

  • Initial rating: 2000 → range = 2000–2500
  • After win: rating = 2008
  • New seek still uses 2000–2500 (should be 2008–2508)

The web version of Lichess does not have this issue, as it has already been addressed there.

---

Fix

Recompute the rating range at the moment of seek creation using the latest account rating.

Instead of using the stored customRatingDelta directly, the final rating range is derived dynamically from the current user rating before sending the request.

---

Implementation

• Updated seek creation logic in create_game_service.dart
• Applied withRatingRangeOf(account) before calling createSeek(...)
• Ensures rating range is always aligned with the current user rating

---

Result

• Rating range updates correctly after each game
• Behavior is now consistent with the web version
• Prevents stale matchmaking filters

---

Notes

• Fix verified logically against the existing web implementation
• No UI changes required
• No breaking changes

---

Acknowledgement

Thanks for the great work on the new mobile app.

[veloce]

Thanks for trying to fix this. But I am not sure about your fix.

Looks to me that .withRatingRangeOf(account) is already called on new opponent because of the ratingDelta being present.

I suspect the problem is that the account doesn't get refreshed when calling for a "new opponent".

I believe that invalidating the account provider here:

mobile/lib/src/view/game/game_screen.dart

Line 193 in 1fda24c

final savedSetup = ref.read(gameSetupPreferencesProvider);

would be a much easier fix.

Anyway just the code and the description you provided, however how detailed it was it not enough for me to review this properly.

I would need to see the fix in action in a screen recording. And also a test that proves the fix and prevent any regression.