The following error is logged to the console: TypeError: Converting circular structure to JSON
Have you considered adding a test to your test suite that loads every part of the site and verifies that no errors are generated merely from loading a part of the site? These kinds of errors on the site are semi-frequent, with a new issue of this type appearing once every few weeks or so. A test like that would completely eliminate this class of errors.
Do you have dev console open all the time? Why?
Where is the error originating from? It’s it handled at all? Is it WK code, or from a third party library?
And why does it matter, if the site works perfectly? You’ll find ‘errors’ in dev console all the time across the entirety of the internet.
I run a script that alerts me whenever an uncaught javascript exception occurs on WaniKani because it is useful when developing userscripts and also helps me find out when WaniKani introduces a change that breaks a script without warning. For example, some of the recent bug fixes I wrote for the DoubleCheck script were aided by this.
Semi-regularly, WaniKani does accidentally introduce new bugs to the site. These are often actual bugs, not just things that result in an error message. Often, these bugs do also cause an error to be logged to the console. For example, they had an issue with a null value being introduced to the review queue a couple weeks ago that could have been caught with a test script that does some random review activity and then checks the console for errors. In at least one case, this bug actually made it impossible for me to submit reviews and I had to manually run some javascript in the dev console in order to get reviews working again. Another example a few weeks before that is when they made a configuration change that accidentally rendered the whole site inaccessible, when they fixed it, their fix didn’t fix the api and they didn’t realize that the api wasn’t fixed. During that time, apps weren’t able to access the api at all. If they had an automated system that made a few api calls and notified them when there are errors, this kind of bug would have been caught immediately. So I really do think it would reduce the likelihood of bugs that actually impact peoples’ WaniKani experience if they had automated tests that do checks for errors being thrown.
Also, when developing userscripts, if the console has a bunch of error messages from WaniKani itself logged to it, it makes it easier to miss any errors from the script you are developing.
Of course, it takes time and effort to implement tests like these and it’s ultimately up to the WaniKani staff to decide whether it’s worth it. One of the wonderful things about the WaniKani team is that they are great about being willing to listen to constructive feedback, even if they ultimately make a different judgment call.