From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 5170F1FF13B for ; Wed, 03 Jun 2026 13:59:38 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2CCC09B02; Wed, 3 Jun 2026 13:59:38 +0200 (CEST) Message-ID: Date: Wed, 3 Jun 2026 13:59:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [RFC PATCH datacenter-manager 1/4] server: connection: multi client: use correct client error for retrying To: Thomas Lamprecht , pdm-devel@lists.proxmox.com References: <20260529133026.3149896-1-d.csapak@proxmox.com> <20260529133026.3149896-2-d.csapak@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1780487937705 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.049 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment 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: V3HPMZ2I5XUBTCOWXJ4SJROX6CF34LQC X-Message-ID-Hash: V3HPMZ2I5XUBTCOWXJ4SJROX6CF34LQC X-MailFrom: d.csapak@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 Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 6/3/26 1:48 PM, Thomas Lamprecht wrote: > Am 01.06.26 um 09:19 schrieb Dominik Csapak: >> >> nice thanks, but after reading the commits wouldn't this now not also >> retry the api call if it was a client one? >> >> it the first node returns a 'Client' error for any api call, >> it will still retry on the second node, etc. ? >> >> the new code only does not retry the first node if it was a client >> error? > > yeah, you're right, this was still not completely right, oof tracing > the error behavior of the client libs and these edge cases here are > really not that trivial... I pushed another follow-up, would be glad > if you could cross-check that too for sanity: > > https://git.proxmox.com/?p=proxmox-datacenter-manager.git;a=commitdiff;h=c713876671f88d80bafdd3a1e7263644b4559da2 > I took a short look and it seem mostly OK FWICT One thing that came to my mind though: I think our API is not fully compliant with what the HTTP spec defines as idempotent though: from https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2 --- Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent. --- and --- Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe. --- so of the methods we use in pve/pbs, only POST is not idempotent per the spec, but e.g. we can use 'PUT' for making non-idempotent changes to a vm config (for example adding a disk to a VM, this will create a disk and make any in the same slot unused) I'm not super sure if we can get an client error here in a way that would process the request with side effects on pve side and still trigger a retry on the pdm side, so I doubt this will make a difference in practice. Still wanted to mention it.