public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup v2 1/2] rest-server/worker-task: replace newlines with '\n' in task result
Date: Mon, 11 Oct 2021 15:37:20 +0200	[thread overview]
Message-ID: <a97c83e5-53f7-8615-bf17-458fa3277fd5@proxmox.com> (raw)
In-Reply-To: <2d4963c3-d86c-b720-33db-239134320f43@proxmox.com>

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 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)
> 

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 sleep deprived, that 
is create_state.

> 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

percent encoding is an actual format than can be rendered again nicely, just randomly
mapping the \n control code (0x0A) to 0x5C 0x6E, without escaping existing (literal) \n
just isn't a used format, at least FWICR, that's my point in provoking that question.

> 
>>
>>>>
>>>>> 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> {
>>>>>
>>>>
>>>
>>>
>>
> 
> 
> 
> _______________________________________________
> pbs-devel mailing list
> pbs-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel





  reply	other threads:[~2021-10-11 13:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 12:14 Dominik Csapak
2021-10-11 12:14 ` [pbs-devel] [PATCH proxmox-backup v2 2/2] backup-proxy: fix api log reopen send_command calls Dominik Csapak
2021-10-11 12:57   ` [pbs-devel] applied: " Thomas Lamprecht
2021-10-11 13:12 ` [pbs-devel] [PATCH proxmox-backup v2 1/2] rest-server/worker-task: replace newlines with '\n' in task result Thomas Lamprecht
2021-10-11 13:14   ` Dominik Csapak
2021-10-11 13:23     ` Thomas Lamprecht
2021-10-11 13:30       ` Dominik Csapak
2021-10-11 13:37         ` Thomas Lamprecht [this message]
2021-10-11 13:57           ` Dominik Csapak
2021-10-12  5:33             ` Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a97c83e5-53f7-8615-bf17-458fa3277fd5@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal