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

Return an error when scheduling a reducer with a long delay #77

Merged
merged 1 commit into from
Jul 13, 2023

Commits on Jul 13, 2023

  1. Return an error when scheduling a reducer with a long delay

    Prior to this commit, it was possible for a module to crash SpacetimeDB
    by scheduling a reducer with a delay longer than ~2yrs.
    This was due to our use of `tokio_utils::time::DelayQueue` to handle scheduling.
    `DelayQueue`'s internal data structure imposes a limit of 64^6 ms on delays,
    a little more than two years.
    Attempting to insert with a delay longer than that panics.
    
    With this commit, we avoid the panic by checking ourselves that the requested delay
    is not longer than 64^6 ms.
    This requires bubbling a `ScheduleError` up from `Scheduler::schedule`
    to `WasmInstanceEnv::schedule`, where it is converted into a `RuntimeError`
    which crashes the module.
    
    `Scheduler::schedule` could also fail because its transaction to compute a new id
    was fallible. This seems unlikely to ever fail, and if it does, we have bigger problems,
    so `unwrap`ping might still be reasonable for that case,
    but this commit converts it into a handle-able `Err`or anyway,
    as there's essentially no cost in complexity to doing so.
    gefjon committed Jul 13, 2023
    Configuration menu
    Copy the full SHA
    c893aaa View commit details
    Browse the repository at this point in the history