Re: [PATCH manager v7 17/24] ui: guest ID selector: show the error returned by nextid

[Fiona Ebner <f.ebner@proxmox.com>]

Am 12.10.26 um 4:23 PM schrieb Michael Köppl:
> On Fri Oct 9, 2026 at 6:22 PM CEST, Fiona Ebner wrote:
>> Am 05.10.26 um 4:50 PM schrieb Michael Köppl:
>>> The guest ID field validates IDs through the /cluster/nextid endpoint
>>> and reported any failure, including failed requests, as the ID being
>>> in use. Show the error the endpoint returns instead, so that the
>>> actual reason for rejecting an ID is visible. This is also needed for
>>> the endpoint to reject IDs that are not in use, but forbidden by the
>>> next-id datacenter option.
>>>
>>> Signed-off-by: Michael Köppl <m.koeppl@proxmox.com>
>>> ---
>>>  www/manager6/form/GuestIDSelector.js | 8 +++++---
>>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/www/manager6/form/GuestIDSelector.js b/www/manager6/form/GuestIDSelector.js
>>> index f3160a744..fdf9e7610 100644
>>> --- a/www/manager6/form/GuestIDSelector.js
>>> +++ b/www/manager6/form/GuestIDSelector.js
>>> @@ -27,7 +27,7 @@ Ext.define('PVE.form.GuestIDSelector', {
>>>          }
>>>
>>>          if (me.validateExists === false && me.rejected) {
>>> -            return me.inUseID;
>>> +            return me.nextIDError;
>>>          }
>>>
>>>          return true;
>>> @@ -37,7 +37,6 @@ Ext.define('PVE.form.GuestIDSelector', {
>>>          var me = this;
>>>          var label = '{0} ID';
>>>          var unknownID = gettext('This {0} ID does not exist');
>>> -        var inUseID = gettext('This {0} ID is already in use');
>>
>> Nit: it's a bit unfortunate that we lose this message with gettext().
>> Can we somehow distinguish this and the enforcement case and still show
>> it if it's not the enforcement case? We do cache the guest list in the
>> UI, so maybe checking that, without even needing to do a 'nextid' API
>> call then? Could also be a follow-up, but would be nice for UX.
> 
> Yeah true, it's not really worth losing the translation here. I think it
> makes sense to always go through nextid, though. Because if we're
> relying on the cached guest list, there could be cases where e.g. the
> creation of a guest is blocked if the guest list hasn't been refreshed
> since a guest was removed and we check against that cached list. Always
> making the request here would be worth it IMO.
> 

Ack, fair point!