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

Better way to start recurring timers #414

Open
SebastienGllmt opened this issue Aug 10, 2024 · 0 comments
Open

Better way to start recurring timers #414

SebastienGllmt opened this issue Aug 10, 2024 · 0 comments

Comments

@SebastienGllmt
Copy link
Contributor

SebastienGllmt commented Aug 10, 2024

Background

Often times, you want a recurring global timer (ex: a global leaderboard reset every 24hrs)

The way this is implemented in Paima typically now is that you have an event that, when called, schedules another instance of itself 24hrs later

However, this creates an issue: who calls this STF transition the very first time to start off the process?

Current solution

Right now, the current solution is to create a database migration that starts on the first block that schedules the first STF right away

However, this is problematic because:

  1. It feels super hacky and unintuitive
  2. It's fragile, because it breaks every time we change the Paima database structure

Improved solution

When defining your state transition function, I think it also makes sense to enable a way to export some kind of startup code that can schedule the first instance of these timers through an API that is more stable than writing raw DB queries

Note that this is a 2nd issue in UX improvements for timers. You can see #413 for the other one

@SebastienGllmt SebastienGllmt changed the title Better way to start timers Better way to start recurring timers Aug 10, 2024
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

1 participant