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

Boot Sequence execution may be delayed by earlier (overdue) FarmEvent sequence executions #1493

Open
jsimmonds2 opened this issue Apr 30, 2022 · 2 comments

Comments

@jsimmonds2
Copy link
Contributor

For the case where FBOS has been down (powered off, e.g.) for more than 15 minutes and an existing Sequence Farm Event execution becomes due within a time window starting 15 minutes prior to boot up, then the overdue Farm Event sequence will run before the Boot Sequence (see pic.)

I'd like to work on a solution but first I have questions :)

  • Does FBOS reaally need to deal with overdue executions scheduled 15 minutes in the past ?
    (@RickCarlino was surprised the code did this)
  • The CeleryScript Scheduler begins work on these overdue executions even well before the firmware is ready so they fail if they need the firmware !
    What is the desired user story here ?

Thanks 🙂

Screenshot from 2022-04-30 14-16-48

@roryaronson
Copy link
Member

@jsimmonds2 I think handling the overdue executions was originally to help users who scheduled sequence events too closely together. For example, if a sequence was scheduled at 7:20 took 1 minute and 3 seconds to complete, that would cause a sequence scheduled at 7:21 to get skipped. However, 15 minutes is an excessively long grace period I think. We could reduce that period to 1 minute, or remove that functionality altogether if it allows FBOS test coverage and overall code maintainability to increase. Any affected users will simply need to space their sequence executions farther apart or combine the back-to-back executions into a single sequence to avoid having to pay attention to how long things take to finish.

Any executions that were scheduled to occur while the device is powered off (or not fully booted) should be thrown out to avoid runtime errors (lack of firmware) and just because that is somewhat unexpected behavior in my opinion.

Thanks for looking into this @jsimmonds2!

@jsimmonds2
Copy link
Contributor Author

Thanks for looking into this @jsimmonds2!

@roryaronson . . and thanks for your informative reaction !

Will submit a PR, based on this, very soon.

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