Re: [pve-devel] [PATCH pve-network 1/2] fix #7077: Improve error messages for ID length mismatch

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

Am 30.01.26 um 9:23 AM schrieb Arthur Bied-Charreton:
> On Thu, Jan 29, 2026 at 06:38:50PM +0100, Thomas Lamprecht wrote:
>> Am 21.01.26 um 11:34 schrieb Arthur Bied-Charreton:
>>> Add explicit length checks to ID validation functions to provide clearer
>>> error messages in case of length mismatches
>>
>> A few of these checks might be also done by setting the "maxLength" and/or the
>> "minLength" property in the matching "register_standard_option" schema definition.
>> Could you check that? Would be IMO better to reuse the schema capabillities, and
>> that way, this limits would be also visible in the api schema directly.
>>
>>
> Hey Thomas, thanks for the feedback, I did not think about that.

Not Thomas, but taking the freedom to respond :)

> After looking into this, it seems like we could get rid of most of the parse_*_id functions
> (and probably others as well), but this would require changing PVE::JSONSchema::check_format

Do you mean check_prop() here?

> to check in the following order: 
> 
> `length -> pattern -> custom format fn`
> 
> as opposed to currently:
> 
> `custom format fn -> pattern -> length`
> 
> In the JSON Schema validation's current implementation, the length parameters are effectively ignored 
> due to the pattern/format function being checked beforehand. Do you see any issue with changing the 
> validation order?

AFAICS, changing the order does not change the execution flow. For any
violation, add_error() is called and then the function returns. So for
inputs with multiple violations, changing the order of checks just
changes which error message is present. When messages about length are
more telling to the user (and I think that's true in most cases), it is
an improvement if they are preferred.

Do you have a good reason for also changing the order between the format
fn and pattern? Are there even cases where both are used? If there are
such cases, I guess it depends on the format fn implementation whether
the error message from there is more telling than "value does not match
the regex pattern". What do you think?