On 4/29/20 10:52 AM, Fabian Grünbichler wrote:
> so that API paths that raise an exception while holding a CFS lock
> properly propagate that exception to the client, instead of the
> stringified version with added noise about locks added to the front.
>
> Signed-off-by: Fabian Grünbichler <f.gruenbich...@proxmox.com>
> ---
>
> Notes:
> there seems to be nothing that matches on the prefix added by cfs_lock.
>
> some API calls in pve-access-control, pve-storage and Replication would
> now
> benefit from raising (parameter) exceptions instead of a plain death while
> having a config file locked (mainly checking for duplicates when adding
> entries)
>
> data/PVE/Cluster.pm | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/data/PVE/Cluster.pm b/data/PVE/Cluster.pm
> index b4de989..cce681b 100644
> --- a/data/PVE/Cluster.pm
> +++ b/data/PVE/Cluster.pm
> @@ -609,7 +609,13 @@ my $cfs_lock = sub {
> alarm($prev_alarm);
>
> if ($err) {
> - $@ = "error with cfs lock '$lockid': $err";
> + if (ref($err) eq 'PVE::Exception') {
> + # re-raise defined exceptions
> + $@ = $err;
> + } else {
> + # add lock info for plain errors
> + $@ = "error with cfs lock '$lockid': $err";
> + }
> return undef;
> }
>
>
applied, followed up with fixing the trailing whitespace you introduced and
adapting
the old "plain error" prefix message (which was there since the beginning of
time ^^)
thanks!
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
