From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 78BC474BFE for ; Mon, 11 Oct 2021 15:24:01 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6D44C2124A for ; Mon, 11 Oct 2021 15:24:01 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id E1B3A2123F for ; Mon, 11 Oct 2021 15:24:00 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B4B8445D09 for ; Mon, 11 Oct 2021 15:24:00 +0200 (CEST) Message-ID: Date: Mon, 11 Oct 2021 15:23:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Thunderbird/94.0 Content-Language: en-US To: Dominik Csapak , Proxmox Backup Server development discussion References: <20211011121432.1006944-1-d.csapak@proxmox.com> <9594ead4-8077-c604-b1fc-541be829bd67@proxmox.com> <9dcaa7de-c32a-00c0-f8bd-1d801e7e1325@proxmox.com> From: Thomas Lamprecht In-Reply-To: <9dcaa7de-c32a-00c0-f8bd-1d801e7e1325@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.207 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup v2 1/2] rest-server/worker-task: replace newlines with '\n' in task result X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 13:24:01 -0000 On 11.10.21 15:14, Dominik Csapak wrote: > On 10/11/21 15:12, Thomas Lamprecht wrote: >> On 11.10.21 14:14, Dominik Csapak wrote: >>> we parse the task result from the last line, so we should not print a= >>> new line in the task result, else we get an 'unknown' task state >>> >> >> isn't the issue that we already print the newline in the file_logger's= log method >> this is using underneath and we could get two newlines (i.e. a last em= pty line) >> which then failed to parse? >=20 > no in my case the issue is that the message contained a newline in the = middle: hmm, ok, and example where/how it happens could have helped then here ;)= > --8<-- > 2021-09-28T08:34:00+02:00: TASK ERROR: reopen commands failed, proxy: u= nable to parse parameters (expected json object) > ; api: unable to parse parameters (expected json object) > -->8-- Yeah, but why replacing it with a literal \n then? Why not percent encodi= ng or fixing it at the root in create_state? >> >>> Signed-off-by: Dominik Csapak >>> --- >>> no changes >>> =C2=A0 proxmox-rest-server/src/worker_task.rs | 2 +- >>> =C2=A0 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/proxmox-rest-server/src/worker_task.rs b/proxmox-rest-se= rver/src/worker_task.rs >>> index 51394549..a8899ab9 100644 >>> --- a/proxmox-rest-server/src/worker_task.rs >>> +++ b/proxmox-rest-server/src/worker_task.rs >>> @@ -494,7 +494,7 @@ impl TaskState { >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 match self { >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 TaskState::Error { message, .. } =3D> format!("TASK ERROR: {}",= message), >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 other =3D> format!("TASK {}", other), >>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }.replace('\n', "\\n") //= no newline in task result >> >> Why not `.trim_end()` ? A literal \n seems rather odd to me.. >> >> Comment suggestion: >> >> // our consumer already add \n where required, so avoid double-newline= >=20 > again that was not the issue well, the comment was not really helpful in that case either.. Also, in that case it would make more sense to operate on the TaskState::= Error branch or avoid setting such a bad state in the first place.. >=20 >> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >>> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fn from_endtime_and_message(end= time: i64, s: &str) -> Result { >>> >> >=20 >=20