From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <d.csapak@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 6983474C6B
 for <pbs-devel@lists.proxmox.com>; Mon, 11 Oct 2021 15:30:48 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 46E5C21315
 for <pbs-devel@lists.proxmox.com>; Mon, 11 Oct 2021 15:30:48 +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 A499E2130A
 for <pbs-devel@lists.proxmox.com>; Mon, 11 Oct 2021 15:30:47 +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 3D2AC45CDD;
 Mon, 11 Oct 2021 15:30:47 +0200 (CEST)
Message-ID: <2d4963c3-d86c-b720-33db-239134320f43@proxmox.com>
Date: Mon, 11 Oct 2021 15:30:46 +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: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox Backup Server development discussion <pbs-devel@lists.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>
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <ec7117d4-3a7e-ca8d-bb42-cf23ea8011e7@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.299 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:30:48 -0000

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 the middle:
> 
> hmm, ok,  and example where/how it happens could have helped then here ;)

thats fair ;)

> 
>> --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 encoding
> or fixing it at the root in create_state?

i was going to find the root cause (i do not think its in create state, 
but where the error is generated)

but wanted to have a generic method to not have a wrong task state even
when it happens again somewhere

imho, percent encoding(%0A) is not nicer in this context here than \n

> 
>>>
>>>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>>>> ---
>>>> no changes
>>>>    proxmox-rest-server/src/worker_task.rs | 2 +-
>>>>    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 {
>>>>            match self {
>>>>                TaskState::Error { message, .. } => format!("TASK ERROR: {}", message),
>>>>                other => format!("TASK {}", other),
>>>> -        }
>>>> +        }.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
>>
>> 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..

you're right, thats a better place

> 
>>
>>>
>>>>        }
>>>>          fn from_endtime_and_message(endtime: i64, s: &str) -> Result<Self, Error> {
>>>>
>>>
>>
>>
>