Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eastern Rapid Tourney does not get scheduled #16018

Open
isaacl opened this issue Sep 6, 2024 · 2 comments
Open

Eastern Rapid Tourney does not get scheduled #16018

isaacl opened this issue Sep 6, 2024 · 2 comments

Comments

@isaacl
Copy link
Member

isaacl commented Sep 6, 2024

The eastern standard rapid is scheduled for 07:00. The intended timeline is:

Day 0 07:00: Eastern standard rapid begins
Day 0 07:05: Eastern standard for Day 1 is scheduled.

Instead what happens is:

Day 0 06:00 Hourly rapid with random opening begins
Day 0 06:05 Hourly rapid with random opening is scheduled for Day 1, with a 117min run time
Day 0 07:05 Eastern standard rapid Plan for Day 1 is created, but it conflicts with the hourly rapid already scheduled. 

So the eastern standard rapid never gets scheduled.

@isaacl
Copy link
Member Author

isaacl commented Sep 6, 2024

Not sure how best to detect or handle bugs like this.. Maybe the opening hourlies should not roll over to next day?

@isaacl
Copy link
Member Author

isaacl commented Sep 6, 2024

I could probably write some tests to check that the usurped tourney has same or lower freq...

isaacl added a commit to isaacl/lila that referenced this issue Sep 10, 2024
- Adjust daily overlap to 11.5 hour interval for a conflict,
  fixing a bug where antichess daily (00:00) does not get
  scheduled on the same day as the antichess weekly, even though
  they are 19 hours apart.
  The effect of this can be seen in the snapshot test (9/5 Daily RK)
- Wrote a usurp test which checks a full month of tourneys. This test
  runs in .4s on my laptop thanks to a new, and faster, implementation
  of pruneConflicts.
  Although the faster impl could be used in production, the
  performance difference is not that significant as it's run with
  fewer tourneys. So I've opted to keep the existing, and simpler,
  pruneConflicts method for use in production.
  This is a trade-off between the cost of keeping two methods
  in sync, vs depending on a more complicated and fragile
  pruneConflicts implmentation.
- Delete Eastern Rapid tourney, which was not getting scheduled
  and causes the new usurp test to fail (see lichess-org#16018)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants