Re: [PATCH proxmox-backup v1 1/2] fix #7400: api: gracefully handle corrupted job statefiles

["Michael Köppl" <m.koeppl@proxmox.com>]

On Thu Mar 19, 2026 at 9:05 AM CET, Christian Ebner wrote:
> On 3/18/26 6:22 PM, Michael Köppl wrote:
>> On Tue Mar 17, 2026 at 5:07 PM CET, Michael Köppl wrote:
>> 
>> [snip]
>> 
>>>   };
>>>   use pbs_config::prune;
>>>   use pbs_config::CachedUserInfo;
>>> @@ -73,10 +73,13 @@ pub fn list_prune_jobs(
>>>       let mut list = Vec::new();
>>>   
>>>       for job in job_config_iter {
>>> -        let last_state = JobState::load("prunejob", &job.id)
>>> -            .map_err(|err| format_err!("could not open statefile for {}: {}", &job.id, err))?;
>>> -
>>> -        let mut status = compute_schedule_status(&last_state, Some(&job.schedule))?;
>>> +        let mut status = match JobState::load("prunejob", &job.id) {
>>> +            Ok(last_state) => compute_schedule_status(&last_state, Some(&job.schedule))?,
>>> +            Err(err) => {
>>> +                log::error!("could not open statefile for {}: {}", &job.id, err);
>> 
>> Since I'm currently preparing v2, would it make sense to instead make
>> this a warning? Not quite sure about it, but displaying an error to the
>> user and then just continuing (and having self-healing behavior) seems a
>> bit odd to me.
>
> IMO it makes sense as an error. There was an error reading the file 
> after all. And you might not always be able to self-heal. E.g. what if 
> you cannot re-write the state file (although this should be logged as well).

Ack, I see your point. Thanks for the feedback, I'll leave it as an
error.

>
> Further, I do not expect these to show up frequently and the error 
> message could be adapted to include the default being used as fallback?

Yeah, something like "could not open statefile for {}: {} - falling back
to default job schedule status". I'll adapt it and send the v2.