For the moment invalid gtfs remove the dataset from the API at startup.
If the GTFS becomes invalid while reloading, the old one is kept (and a sentry error is issued).
There are several flows in this approach:
startup
We want at least to keep the invalid dataset and mark it as invalid in the / api.
An even nicer approach would be to mark it as invalid at try again to load it later (once a day ?). This would imply a bigger refactoring of the code since the DatasetActor would return an option (or result), but I think it would be not that bad.
We should also check if the sentry message marking an invalid dataset is send, I don't see them on sentry.
base schedule reloading
Retrying every 5mn seems a bit overkill 🤔 Maybe we should have an exponential backof, and a limit afterward ?
It seems way less important than the previous point though.
For the moment invalid gtfs remove the dataset from the API at startup.
If the GTFS becomes invalid while reloading, the old one is kept (and a sentry error is issued).
There are several flows in this approach:
startup
We want at least to keep the invalid dataset and mark it as invalid in the
/api.An even nicer approach would be to mark it as invalid at try again to load it later (once a day ?). This would imply a bigger refactoring of the code since the
DatasetActorwould return an option (or result), but I think it would be not that bad.We should also check if the sentry message marking an invalid dataset is send, I don't see them on sentry.
base schedule reloading
Retrying every 5mn seems a bit overkill 🤔 Maybe we should have an exponential backof, and a limit afterward ?
It seems way less important than the previous point though.