From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 3FDCD1FF13E for ; Fri, 06 Feb 2026 13:07:24 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 65BCE27C83; Fri, 6 Feb 2026 13:07:56 +0100 (CET) Date: Fri, 6 Feb 2026 13:07:20 +0100 From: Arthur Bied-Charreton To: Fiona Ebner Subject: Re: [pve-devel] [PATCH pve-network 1/2] fix #7077: Improve error messages for ID length mismatch Message-ID: References: <20260121103407.187187-1-a.bied-charreton@proxmox.com> <20260121103407.187187-5-a.bied-charreton@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770379562702 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.798 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 Message-ID-Hash: UMLA3YKZZLCKNND3EKN5VPYKNFNAWGET X-Message-ID-Hash: UMLA3YKZZLCKNND3EKN5VPYKNFNAWGET X-MailFrom: a.bied-charreton@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 CC: Proxmox VE development discussion , Thomas Lamprecht X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, Feb 06, 2026 at 10:40:14AM +0100, Fiona Ebner wrote: > 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? > Yes I do, got the names confused -_- Thanks! > > 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. > That is what I thought/observed as well. > 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? I do not, I wrongly operated under the assumption that format fns would always have the kind of error message we are trying to get rid of. It is true that custom error messages are unlikely to be *less* telling than regex errors, the correct order is more length -> fn -> regex. Thanks for catching that! Now since a lot of the registered format functions only check values against their expected lengths and patterns, they could be fully replaced by registering schemas with register_standard_option instead of custom code. I will submit a v2 with these changes after I made sure that removing the registered formats does not result in any regressions. Of course if anyone already knows about some off the top of their head, I would be thankful for any tips :).