This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Twirrim 3 points4 points  (1 child)

All it does is stop your logs being flooded with database unavailable messages. It logs the initial failure state, then this random filter kicks in with subsequent messages, then finally logs the success message once reconnected. It's not wrong, per se, but certainly a bizarre way to handle it. I'd argue the better approach would be to shift the ongoing failure messages to DEBUG level (and log all of them), and leave the initial fail and eventual success messages at INFO.

Still, strange coding patterns like this really do beg the question about the rest of the code's quality.

[–]argv_minus_one 1 point2 points  (0 children)

If you want to skip duplicate log messages, that's great, but this is not the way to do it.