From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 3E0D41FF0B0 for ; Tue, 27 Oct 2026 11:31:38 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id BC7AC2130C; Tue, 27 Oct 2026 11:31:37 +0100 (CET) Message-ID: Date: Tue, 27 Oct 2026 11:31:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH proxmox-backup] api: gc status: pass schedule instead of UPID to schedule helper To: Jonas Theisen , pbs-devel@lists.proxmox.com References: <20261022161612.331793-1-j.theisen@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: <20261022161612.331793-1-j.theisen@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793097093870 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.501 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: PBUX62NNDNOKRMSLH2ERDBJUZ26W6JOQ X-Message-ID-Hash: PBUX62NNDNOKRMSLH2ERDBJUZ26W6JOQ X-MailFrom: c.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 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 Tested-by: Christian Ebner