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 B30581FF13F for ; Thu, 04 Jun 2026 18:30:40 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9E20571DD; Thu, 4 Jun 2026 18:30:39 +0200 (CEST) Message-ID: <17a36c9d-d652-4b43-a16d-ee7bdfffac8b@proxmox.com> Date: Thu, 4 Jun 2026 18:30:05 +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: Dominik Csapak , pdm-devel@lists.proxmox.com References: <20260529133026.3149896-1-d.csapak@proxmox.com> <20260529133026.3149896-2-d.csapak@proxmox.com> Content-Language: en-US, de-DE From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1780590568001 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.005 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: 77J74GMFNBLXZDANSG4TJF3PQJP3PFF5 X-Message-ID-Hash: 77J74GMFNBLXZDANSG4TJF3PQJP3PFF5 X-MailFrom: t.lamprecht@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 03/06/2026 13:59, Dominik Csapak wrote: > 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. The digest-check should catch the repeated call though, as long as we send that along, we're fine (besides maybe 1. add cfg entry, connection fails on return but PVE processed it 2. another request deletes that cfg immediately again 3. second retried add hits PVE and digest is again the same; but tbh., that's an rather theoretical edge case and would require multiple independent automation stacks interfering with each other, which leads to odd effects in any case.