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
The work done in #107/#109 already improved the boot process by ensuring that a dataset is not "unregistered" (disappears from the routes) completely until next deploy if the static part is not available at boot time.
After #109 is merged, though, in case of unavailability at boot, the dataset download will only be retried 24h later at the moment, via this code:
Detecting the unavailability (at boot and also later) and rescheduling with shorter timeframes (possibly with a form of backoff) would be a real improvement.
Todos
Figure out how to move forward in time, to implement proper tests on this workflow. It could be done via introspection of scheduled run_interval in Actix, if available, or via another form of tweak.
Make sure to avoid cascading downloads (e.g. all of a sudden, we end up downloading multiple times) - see cascading failures in distributed systems for the overall idea
The text was updated successfully, but these errors were encountered:
The work done in #107/#109 already improved the boot process by ensuring that a dataset is not "unregistered" (disappears from the routes) completely until next deploy if the static part is not available at boot time.
After #109 is merged, though, in case of unavailability at boot, the dataset download will only be retried 24h later at the moment, via this code:
transpo-rt/src/actors/update_actors.rs
Lines 54 to 64 in ee95aa2
Detecting the unavailability (at boot and also later) and rescheduling with shorter timeframes (possibly with a form of backoff) would be a real improvement.
Todos
run_interval
in Actix, if available, or via another form of tweak.The text was updated successfully, but these errors were encountered: