Re: [PATCH proxmox-backup] api: gc status: pass schedule instead of UPID to schedule helper

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

On 10/22/26 6:16 PM, Jonas Theisen wrote:
> Since the GC job status was introduced and then refactored in [1]
> the last GC run's UPID has been passed as the schedule argument
> of compute_schedule_status().
> A UPID never parses as a calendar event, so the computed next run
> was always None, and it was then recomputed from the GC schedule
> in a separate step after the fact.
> 
> Pass the configured GC schedule instead and use the helper's result
> directly. This drops the duplicated computation, and the next run
> of GC jobs is now derived from the job state file in the same way as
> for sync, verify, prune and tape backup jobs. Previously, the base
> was the last run's end time from the in-memory GC status, or the
> current time if there was none, which ignored the job state that
> the proxy's scheduler relies on.
> 
> [1] https://lore.proxmox.com/pbs-devel/20260319110318.70346-2-m.koeppl@proxmox.com/
> 
> Signed-off-by: Jonas Theisen <j.theisen@proxmox.com>

Thanks for this cleanup!

Changes fix the incorrect upid passing and duplicate job state 
loading/computation when the datastore instance has an in-memory status.

They do however also change the error logging behavior on calendar event 
parsing and next runtime calculation, which are now silently ignored. 
This is however in line with the rest of the job types, so acceptable IMO.

Tested that this does not lead to changed behaviour when the .gc-status 
is not present yet and that `/admin/datastore/{store}/gc` and 
`/admin/gc` still return consistent information.

Reviewed-by: Christian Ebner <c.ebner@proxmox.com>
Tested-by: Christian Ebner <c.ebner@proxmox.com>