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

[Christian Ebner <c.ebner@proxmox.com>]

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).

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?