Re: [pdm-devel] [RFC proxmox{, -yew-comp, -datacenter-manager}/yew-mobile-gui v2 0/7] Add fallback variant to enum properties in Proxmox VE Rust API types

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 13.11.25 um 16:09 schrieb Stefan Hanreich:
> ### Resubmitting unknown variants
> 
> I had some off list discussions with Dominik and Dietmar regarding how consumers
> of the API (mainly the UI) could handle encountering unknown values when there
> is the possibility of re-submission of this data. Two main options emerged:
> 
> * Resubmitting unknown values as-is, without preventing the user from doing so
> 
> This has the upside of not preventing the user from submitting perfectly fine
> values if they haven't been implemented in PDM. An argument in favor would be
> that the PVE API should act as the last safeguard against invalid objects in the
> configuration anyway, so we could rely on PVE validation only in the case of
> unknown enums.
> The downside is that we need a round-trip to the Proxmox VE API and can only
> show the resulting error in the UI, without any validation. It also does not
> take care of situations where setting a certain, new, enum potentially requires
> special behavior when submitting values.
> 
> * Showing the value, but preventing the user from re-submitting the value
> 
> This is the safest option, since it prevents any, potentially destructive,
> action from the user due to the consumer not being aware of special . It also
> gives the user immediate feedback in the UI, without requiring a round-trip to
> the Proxmox VE instance, but of course users lose the ability to submit
> perfectly valid configurations (without upgrading).
> 
> 
> The answer is, of course, it depends on the context - but in the general case it
> seems preferable to me to show the value to the user, but prevent the user from
> re-submitting the value, since the UI cannot know if there is some special
> handling required in case the new enum variant is used in the UI. If there is a
> good argument for letting the user re-submit certain fields, then that seems
> like a fine option too, but imo *iff* there's good reasoning attached to it.
> 
> What do you think? Any options that were missed?


For the ExtJS UI's we often edit what we know and resend the unknown rest as is,
or drop the unknown rest due to it not getting into any form field and thus
not being present on submit anymore. Depends a bit on the backend and if the
data changed is all in top-level properties or complex properties consisting
of format-strings. For the former it often won't matter (we seldomly have
conflicting values on that level) and for the latter most of our code should
use the generic print/parse property string helpers, which sends that along
again and quite often will do what one expects. It works surprisingly OK,
albeit besides PDM, which doesn't exist for that long, one basically only has
a real likelihood to run into issues when having a PVE cluster with mixed
versions, as otherwise the UI and the backend will closely match anyway.

For PDM I'd go for the "show but not edit" route for now, at least as default.
As you say, there can be exceptions, but that can be decided on a case by
case basis when needed.

Am 13.11.25 um 16:09 schrieb Stefan Hanreich:
> ### Storing unknown Variants
> 
> When only reading and displaying / storing data, then including unknown values
> is desired behavior imo (again, in the general case) - since it allows storing
> data (e.g. metrics) that isn't yet understood but could potentially be
> understood perfectly fine after an upgrade of PDM.
> 

Would not do anything with that, throw away and log as low-severity level,
one always can get send stuff by a (potentially malicious!) backend, if
one cannot understand it, doing nothing is best for the common case.

Am 13.11.25 um 16:09 schrieb Stefan Hanreich:
> ### Unsafe FixedString
> 
> I implemented as_bytes and as_str in FixedString via the unsafe variants of the
> methods and included tests that check for correct behavior of those methods.
> Using the safe variants and panicking here should be fine too imo if we don't
> want to go down that road. FixedString should only get used in rare, exceptional
> cases anyway - and even then not in a hot path. The adaption should be trivial.
> 

Ack.

Am 13.11.25 um 16:09 schrieb Stefan Hanreich:
> ## Adapting the existing code
> 
> One difficulty when adapting the UI was identifying places in which a struct
> gets returned directly from the API, deserialized (but the value isn't used
> anywhere in the frontend), then serialized again and sent back to the backend.
> Since the FixedString serializes indistinguishable from a String, this could
> introduce situations where we submit unkown enum values when instead an error
> should be shown and the user prevented from submitting a form.
> 
> I tried to look at each component in the backend / frontend and check if it uses
> and potentially re-submits am enum without checking its variants for unknown
> values. Since we model enums with checkboxes in the UI and have fixed values
> there, this should usually work and prevent users from submitting values that
> are unknown to the UI. Nevertheless, it's very much possible I missed some
> places, so here some group effort in trying to identify potentially problematic
> spots would be nice.

This is limited to cases where there is an unknown variant/value in the first
place, which is not something that will happen everyday, might even start to
level off for non-major releases in the future (after most important PDM features
got implemented).



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