You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
It feels super hacky and unintuitive
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
The text was updated successfully, but these errors were encountered:
SebastienGllmt
changed the title
Better way to start timers
Better way to start recurring timers
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:
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
The text was updated successfully, but these errors were encountered: