From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pdm-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
	by lore.proxmox.com (Postfix) with ESMTPS id 608331FF15C
	for <inbox@lore.proxmox.com>; Fri, 18 Apr 2025 08:10:45 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id 585D136A34;
	Fri, 18 Apr 2025 08:10:42 +0200 (CEST)
Message-ID: <c3a8b7c7-4adc-4b17-bd47-547b7b2e9a96@proxmox.com>
Date: Fri, 18 Apr 2025 08:10:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox Datacenter Manager development discussion
 <pdm-devel@lists.proxmox.com>
References: <20250416113232.2488103-1-d.csapak@proxmox.com>
 <bf7a59ee-077d-4d64-9536-e03263345985@proxmox.com>
Content-Language: en-US
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <bf7a59ee-077d-4d64-9536-e03263345985@proxmox.com>
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.022 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
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pdm-devel] [PATCH datacenter-manager] ui: resource tree: use
 AsyncPool to cancel obsolete pending loads
X-BeenThere: pdm-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Datacenter Manager development discussion
 <pdm-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pdm-devel>, 
 <mailto:pdm-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pdm-devel/>
List-Post: <mailto:pdm-devel@lists.proxmox.com>
List-Help: <mailto:pdm-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel>, 
 <mailto:pdm-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox Datacenter Manager development discussion
 <pdm-devel@lists.proxmox.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: pdm-devel-bounces@lists.proxmox.com
Sender: "pdm-devel" <pdm-devel-bounces@lists.proxmox.com>

On 4/17/25 17:43, Thomas Lamprecht wrote:
> Am 16.04.25 um 13:32 schrieb Dominik Csapak:
>> Currently, if a new serach term is given, a new load will occur if the
>> INPUT_BUFFER_MS time is reached. Any old in-flight API requests are not
>> canceled, and might still arrive.
>>
>> To prevent that, use an AsyncPool and refresh that when the search term
>> changes.
> 
> I forgot a few details here, but would it be possible to provide a wrapper
> component for such things? I.e. fields where editing will trigger an API
> request. As to me, it feels like this is an easy error to make for any
> such fields, especially as it normally won't be noticed if tested locally
> with <1ms network latency and the often relatively smaller (test) setups,
> where the code querying the data in the backend needs only a few ms too.

mhmm, the AsyncPool is already the helper wrapper we should use for this,
we just have to apply it consistently.

The only special thing we do here is to replace the asyncpool with a new
one in the 'changed' method.

maybe a method for the async pool that takes additionally an id and
replaces the old future with the new one in case there is already
an in flight future with the same name?

(we use the asyncpool to handle multiple futures, so we'd need
to identify them)

> 
> But in any way not something that needs to delay applying this patch.
> 



_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel