From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <t.lamprecht@proxmox.com>
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 6C54674C79
for <pbs-devel@lists.proxmox.com>; Mon, 11 Oct 2021 15:37:22 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 62B99214DD
for <pbs-devel@lists.proxmox.com>; Mon, 11 Oct 2021 15:37:22 +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 8515B214D2
for <pbs-devel@lists.proxmox.com>; Mon, 11 Oct 2021 15:37:21 +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 55A1D45CEE
for <pbs-devel@lists.proxmox.com>; Mon, 11 Oct 2021 15:37:21 +0200 (CEST)
Message-ID: <a97c83e5-53f7-8615-bf17-458fa3277fd5@proxmox.com>
Date: Mon, 11 Oct 2021 15:37:20 +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: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com>
References: <20211011121432.1006944-1-d.csapak@proxmox.com>
<9594ead4-8077-c604-b1fc-541be829bd67@proxmox.com>
<9dcaa7de-c32a-00c0-f8bd-1d801e7e1325@proxmox.com>
<ec7117d4-3a7e-ca8d-bb42-cf23ea8011e7@proxmox.com>
<2d4963c3-d86c-b720-33db-239134320f43@proxmox.com>
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <2d4963c3-d86c-b720-33db-239134320f43@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.206 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
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2021 13:37:22 -0000
On 11.10.21 15:30, Dominik Csapak wrote:
> On 10/11/21 15:23, Thomas Lamprecht wrote:
>> 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 =
empty line)
>>>> which then failed to parse?
>>>
>>> no in my case the issue is that the message contained a newline in th=
e middle:
>>
>> hmm, ok,=C2=A0 and example where/how it happens could have helped then=
here ;)
>=20
> thats fair ;)
>=20
>>
>>> --8<--
>>> 2021-09-28T08:34:00+02:00: TASK ERROR: reopen commands failed, proxy:=
unable 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 enc=
oding
>> or fixing it at the root in create_state?
>=20
> i was going to find the root cause (i do not think its in create state,=
but where the error is generated)
>=20
I do not mean the root cause that logged a newline at the end, we cannot =
avoid the future,
but the one that crates the TaskError enum, and if I'm not completely sle=
ep deprived, that=20
is create_state.
> but wanted to have a generic method to not have a wrong task state even=
> when it happens again somewhere
>=20
> imho, percent encoding(%0A) is not nicer in this context here than \n
percent encoding is an actual format than can be rendered again nicely, j=
ust randomly
mapping the \n control code (0x0A) to 0x5C 0x6E, without escaping existin=
g (literal) \n
just isn't a used format, at least FWICR, that's my point in provoking th=
at question.
>=20
>>
>>>>
>>>>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>>>>> ---
>>>>> no changes
>>>>> =C2=A0=C2=A0 proxmox-rest-server/src/worker_task.rs | 2 +-
>>>>> =C2=A0=C2=A0 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/proxmox-rest-server/src/worker_task.rs b/proxmox-rest-=
server/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=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=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=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-newli=
ne
>>>
>>> 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 TaskStat=
e::Error branch
>> or avoid setting such a bad state in the first place..
>=20
> you're right, thats a better place
>=20
>>
>>>
>>>>
>>>>> =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 fn from_endtime_and_mes=
sage(endtime: i64, s: &str) -> Result<Self, Error> {
>>>>>
>>>>
>>>
>>>
>>
>=20
>=20
>=20
> _______________________________________________
> pbs-devel mailing list
> pbs-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel