Bug: the first game of a new streak is not counted in the streak,
neither in `games played in a row` nor in `max time spent playing`. Bug
is not present if the game is the first one ever under that time
control.
Steps to reproduce: play one rated game using a time control previously
used (e.g. blitz) even though not in the last hour, than go to
`lichess.org/@/<user>/perf/blitz` and note
that both `current streak` at the bottom of the page are still zero.
From the second game the `current streak` of `games played in a row` is
systematically one less than expected, while the other one does not
count the elapsed time of the first game.
Troubleshooting: the bug is due to the call at `Streak.init`
(i.e. `(0, none, none)`) when a game is discontinued from the previous one.
I propose, with this commit, to substitute that call with a new function
inspired by `inc`. This new function is called `res` (from `reset`):
its aim is to set `nb` and `time` dynamically after the first game
of the new streak.
In order to use this new function only in `nb` and `time`
I create a new `apply` function in `Streaks` and `Streak` with an extra
parameter: the reset (`r`) value. w/l streaks still use the old
`apply` function.
There can be very slow queries when these conditions are met:
- two users have thousands of msgs in their convo
- a user has deleted all the messages
- some new messages were posted, less than 100 of them, say 50
- the user who deleted the thousands of messages loads the convo
What happens then is that lila fetches 100 messages for that user,
that have not been deleted by that user.
The query will find the latest 50 non-deleted messages,
then will look for more, and ends up scanning the thousands
of deleted messages. In vain: since messages can only be deleted
up to a point in time. There can't be non-deleted messages older
than a deleted message.
So, we removed the non-deleted condition from the query. We now
just fetch the last 100 messages (with possible skip for pagination),
deleted or not. And we filter them in lila after the fetch.
This guarantees that the DB will no longer scan thousands of
deleted messages.
* Revert "Revert "Improve tournament names translation""
This reverts commit ec10605e20.
* Fix tournament names when `Speed` different from `Perf`
Only `Rapid` and `Classical` are concerned by translation anyway.
8a1a7396f5/modules/rating/src/main/PerfType.scala (L297)
Co-authored-by: kraktus <kraktus@users.noreply.github.com>
* 'api-filter-user-tournaments-by-status' of git://github.com/nnickoloff1234/lila:
Update TournamentRepo.scala
add status filter parameter to users created tournaments api
Thibault Duplessis