benediktarnold commented on issue #824: URL: https://github.com/apache/solr-operator/issues/824#issuecomment-4857175120
Confirming this on the **latest release v0.9.1** (Solr 9.7, GCS repo), and adding the impact on **recurring** backups, which is severe. Our operator runs on GKE Autopilot and is restarted routinely (node auto-provisioning/upgrades), so the precondition described here — backup accepted, operator unavailable, async status later returns `notfound` — is easy to hit without any manual intervention. The key thing to add: for a **recurring** `SolrBackup`, a single stuck `notfound`/`inProgress` collection wedges the *entire* recurrence, not just that collection: - top-level `finished` and `nextScheduled` stay `null`, - the schedule never fires again and `maxSaved` pruning never runs, - every other collection still reports `successful: true`, and no error surfaces. Ours has been frozen at its original `startTimestamp`, with a few per-collection statuses stuck in `notfound`/`inProgress`. The schedule was even changed during that window with no effect, because the recurrence never advanced past the wedged run. Suggestion, in addition to making `notfound` terminal: compute `finished`/`nextScheduled` from *terminal* per-collection states, so one stuck collection can't halt the schedule and `maxSaved` retention indefinitely. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
