Debugging COSMOS

[stanislaw]

Hello again :)

We are continuing our evaluation of the web version of COSMOS. It seems to happen quite often that we see the UI-level bugs that are not easy to report or reproduce. We have confidence that we could investigate and debug some of the bugs or at least report them properly with additional debugging information.

A typical example: we see the 400 and 500 errors in the browser console in several use cases.

We would like to know if the developers of COSMOS could share information about their typical development and debugging workflows that we could adopt in order to be more efficient in detecting and reporting all the issues that we see. Specifically:

• What is the easiest way to debug the backend code? If we see 400 or the 500, what is the shortest path to troubleshoot the error?
• Any other debugging tips?

Again, if there is a focused knowledge about the debugging topic, based on your advice, we would be happy to send a patch to the COSMOS documentation to explain the know-hows.

Thanks.

[ghost]

Hello,

On the surface, one thing that can help a lot in addition to the browser console is the network tab in the browser dev tools. This will show you the actual response from the web server (e.g. was it json with an error message? html page? etc), in addition to any headers and all other data related to the request that returned a 400 or 500. However, the dev tools must already be open when the error occurs in order for this network data to be captured, so I typically just leave that open in the background at all times while I'm working on COSMOS. You can also use a tool like Postman to modify and repeat these XHR requests against the API, but this is something I haven't actually done much with COSMOS.

COSMOS 5 makes use of import map overrides, which can also be useful for debugging. This allows you to serve a COSMOS tool locally instead of from the COSMOS installation in Docker (while still using the backend and core frontend app from Docker), so you can temporarily write in some debugging code and bypass the normal build rules (such as no-console). You can even do this with a remote installation of COSMOS as of 27c3737

1. Open the browser console and enter localStorage.devtools = true and then refresh the page. You should now see a "{...}" button in the bottom right corner of the page.
2. Install yarn dependencies if you haven't already by running yarn in the cosmos-frontend-init directory
3. Serve a tool by running yarn serve in its directory (e.g. COSMOS/cosmos-frontend-init/packages/cosmosc2-tool-tlmviewer). Once this is running, it will give you a URL (e.g. "App running at: - Local: http://localhost:2917/tools/tlmviewer/")
4. Back in the browser, click that "{...}" button, which will open a list of your import map overrides. Click on the one you want to override, and it will open a small dialog modal.
5. Take the URL you got from yarn, append "js/app.js" to it (so the full URL is something like http://localhost:2917/tools/tlmviewer/js/app.js), and put that in the text field. Click "apply override" and refresh the page. You should now be seeing your locally served tool.
6. To stop overriding the tool when you're done, click "{...}", click the tool, and click "disable override" on the dialog. You can hide the "{...}" button again with localStorage.devtools = false

Lastly, backend logs are always useful, and they can be accessed by running docker logs <container ID for the cmd-tlm-api container> optionally with the --follow option (which will behave like tail -f ). Watching these when an error occurs will give you the stack trace and may provide some insight as to why the error occurred. Sometimes it may also be useful to shell into a container with docker exec -it <container ID> /bin/ash so you can poke around, modify files, etc.

Hope this helps