Issue 8101

Title
logging at INFO dumps attachments!
Priority
wish
Status
closed
Superseder
logging request should truncate large data (issue 5228)
Nosy list
ced, pokoli, risto3
Assigned to
Keywords

Created on 2019-02-09.19:26:20 by risto3, last changed 3 months ago by ced.

Messages

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2022-05-31.20:03:42

Duplicate issue5228

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2019-02-09.20:05:27
I do not see the point of invalidating this issue, neither to copy past python documentation.
Author: [hidden] (risto3)
Date: 2019-02-09.20:02:25
https://docs.python.org/3.7/howto/logging.html
namely the section
"The logging functions are named after the level or severity of the events they are used to track. The standard levels and their applicability are described below (in increasing order of severity):
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2019-02-09.19:56:35
Logging calls at info level sounds the right level. But it will be good to have a limit on the formatting of kwargs (but it should be done a a lazy way like logging works). In case such feature is implemented it should probably add a second debug logging with the full arguments.
So I mark it as a wish.
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2019-02-09.19:53:29
> Also, isn't what you're talking about more useful in DEBUG
No, as debug logs more information.

> Is it possible to override the log level by class?
> Then at least one could drop trytond.ir.attachment.Attachment to WARNING

I don't know. 

P.S: Please use the forum for support request.
Author: [hidden] (risto3)
Date: 2019-02-09.19:50:09
Also, isn't what you're talking about more useful in DEBUG
Author: [hidden] (risto3)
Date: 2019-02-09.19:49:34
Is it possible to override the log level by class?
Then at least one could drop trytond.ir.attachment.Attachment to WARNING
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2019-02-09.19:49:05
The BLOB data allows to reproduce the same request which may be useful for reproducing an error as it may depend on the posted data.

So if the only concern is about log size I do not think we can do anything. For me it is expected to have a very log size when logging all the request (which is the case of INFO level)
Author: [hidden] (risto3)
Date: 2019-02-09.19:45:29
log size...  we use attachments for all orders, deliveries, invoices, et cetera

I had no choice but to go to WARNING, but I prefer INFO at this stage.

What value is displaying BLOB information anyway?
Author: [hidden] (pokoli) Tryton committer Tryton translator
Date: 2019-02-09.19:28:37
The data is part of the request parameters and the request parameters are logged on INFO level so I don't see any reason to not log them. 

Could you elaborate why we should not log them?
Author: [hidden] (risto3)
Date: 2019-02-09.19:26:20
Using logging set at INFO, I notice with consternation that attachments are dumped!
Fri Feb 08 08:38:47 2019] INFO:trytond.protocols.dispatcher:<class 'trytond.ir.attachment.Attachment'>.create(*([{'data': b'%PDF-1.4..... +lots of data

Please don't! just log filenames
History
Date User Action Args
2022-05-31 20:03:42cedsetmessages: + msg76844
status: chatting -> closed
superseder: + logging request should truncate large data
2019-02-09 20:05:27cedsetstatus: invalid -> chatting
messages: + msg46899
2019-02-09 20:02:25risto3setstatus: chatting -> invalid
messages: + msg46898
2019-02-09 19:56:36cedsetstatus: invalid -> chatting
messages: + msg46897
component: + trytond
nosy: + ced
2019-02-09 19:53:29pokolisetstatus: chatting -> invalid
messages: + msg46896
2019-02-09 19:50:09risto3setmessages: + msg46895
2019-02-09 19:49:35risto3setstatus: invalid -> chatting
messages: + msg46894
2019-02-09 19:49:05pokolisetstatus: unread -> invalid
priority: bug -> wish
messages: + msg46893
2019-02-09 19:45:29risto3setstatus: need-eg -> unread
messages: + msg46890
2019-02-09 19:28:37pokolisetstatus: unread -> need-eg
nosy: + pokoli
messages: + msg46889

Showing 10 items. Show all history (warning: this could be VERY long)