Consider adjusting default log level to improve developer experience

[devleejb]

Description:
Currently, various events such as PushPull are being logged, which may not be necessary for developers using the yorkie-js-sdk. Additionally, error messages produced periodically by WatchDocument may be difficult for front-end developers to differentiate between intentional errors and actual issues.

Why:

• Developers using the yorkie-js-sdk may not be concerned with events like PushPull.
• Front-end developers may find it challenging to identify whether errors produced by WatchDocument are intended or actual issues.

[gwbaik9717]

I'm interested in issue. can I give it a shot?

[devleejb]

@gwbaik9717
Of course. If you have any questions, feel free to ask.

[gwbaik9717]

Hi, I'm about to make a commit which lowers verbosity by adjusting default LogLevel from Info to Error.

However, I'm not really sure that my commit will fix the second issue which is "Additionally, error messages produced periodically by WatchDocument may be difficult for front-end developers to differentiate between intentional errors and actual issues."

In fact, I couldn't find where the error log periodically logs in my examples in Yorkie-JS-SDK so far...

Is there any way to reproduce the situation?

[krapie]

@gwbaik9717 WatchDocument's periodic error log can be checked only when yorkie server is in cluster mode.

Since our hosted server is in cluster mode, all the applications using our API will get the error.
In the other hand, when you are testing on your own local environment with single server, it will not emit WatchDocument error log because it is not in cluster mode.

So you need to change the url to our Yorkie SaaS API, which is https://api.yorkie.dev to see the error.

Edit: We are working on fixing this issue in our cluster mode.

[gwbaik9717]

Thanks for the comment! I was able to reproduce the issue.

I have one more question.

I've tried to adjust default log to higher level (such as debug, error), but WatchDocument error log still remains.

Apparently, that is because WatchDocument is not using custom logger to manage its logging. (it seems to be using default error logging such as console.error.)

Therefore, I do not get the relationship between the logging configuration and the WatchDocument logs.

[krapie]

I think we can skip WatchDocument error log for now.
This is different kind of issue that yorkie server cluster have to handle.

[gwbaik9717]

Thanks for the comment.

One last question: I'm not sure if this is the right place to ask, but as I read through the yorkie-sdk documentation about the logger, I noticed that the description for LogLevel.Trivial is "Lowest level of verbosity". However, I believe it should be Highest verbosity instead of Lowest, since it logs the most among other log levels.

Is there something I'm missing?

[krapie]

@devleejb @chacha912 Could you check above description?

[chacha912]

Hi @gwbaik9717 🙌

I've tried to adjust default log to higher level (such as debug, error), but WatchDocument error log still remains. Apparently, that is because WatchDocument is not using custom logger to manage its logging. (it seems to be using default error logging such as console.error.) Therefore, I do not get the relationship between the logging configuration and the WatchDocument logs.

• WatchDocument is using a logger. You can find it by searching for [WD]. The net:: errors you're seeing are browser-generated errors that we haven't found a way to control yet. (For reference: https://socket.io/docs/v4/logging-and-debugging/#error-logs-in-the-browser-console, Can´t catch/suppress ERR_CONNECTION_REFUSED socketio/socket.io-client#1178) If you know of any way to prevent these errors from being displayed, please share it with us.

  • 

• However, there are also parts where a logger is not used, as you mentioned. So it might be a good idea to unify all logging in yorkie-js-sdk to use the logger consistently. You can find the related issue here: Unify Error Throwing Methods #696

I noticed that the description for LogLevel.Trivial is "Lowest level of verbosity". However, I believe it should be "Highest verbosity" instead of "Lowest", since it logs the most among other log levels.

• @devleejb, Could you review the documentation for LogLevel.Trivial?

[devleejb]

@chacha912 @gwbaik9717

I noticed that the description for LogLevel.Trivial is "Lowest level of verbosity". However, I believe it should be "Highest verbosity" instead of "Lowest", since it logs the most among other log levels.

I think it is incorrect and confusing.
I have created a GitHub issue with it.
yorkie-team/yorkie-team.github.io#148