[FEAT] Where to find logs for the desktop app?

[bfontaine]

Description
Hello, I still have this annoying issue on the desktop app v1.0.3, but it occurs only on some indices of one cluster so it’s hard to help you reproduce it.
Is there some place I can find logs to troubleshoot the issue?

[cars10]

Elasticvue desktop does not really offer much in terms of logging right now. I attached a version of the current develop branch that has the debug console enabled - you can use the browser console to check for any frontend errors.
elasticvue.zip

• right click anywhere
• inspect element
• console

Thanks for helping me debug this issue!

[cars10]

You can also do that in version 1.0.4 released yesterday - no need to use the provided debug build.

[bfontaine]

Thanks! I downloaded 1.0.4 and opened the console, but I don’t see anything. I also don’t see requests in the network tab when I click on "refresh" on any of the views that have it.

This is what I have in the network tab after having navigated multiple times on all views (Home/nodes/shards/etc) and clicked on "refresh" on indices and shards multiple times:

The only requests I see are those made when I switch cluster, but those are HTML/JS/CSS/font/images, not actual requests to ES.

When it freezes, I can move around in the inspecter tab, but I can’t expand the HTML elements anymore:

Here you can see some little arrows that point down in the HTML view but the content of these elements is not shown, because the inspecter is as frozen as the view. In fact, I did alt+tab to write this here and then go back to ElasticVue, and it turned all white:

(I resized it because we don’t need a large screenshot to see that it’s empty)

[cars10]

Hm, i will add more logging for the desktop app.

Can you reproduce the freezing issue when reindexing via the REST page? Or does it only happen on the indices page when using the reindex functionality?

[bfontaine]

Wait I found the issue: I went to a small index (2.5k documents) on the "Search" page, it froze but only for ~10s or so, then it showed the list of documents and was almost unresponsive but still "usable". The list of documents was very long because the limit was set to 10k records per page; when I set it back to 20, the page became responsive again. I went to a larger index (100M+ documents) and it didn’t freeze.

The issue seems to be that at one point I set the limit to 10k records per page, probably on a small index, and then this configuration was saved for the whole cluster, so on large indices it probably froze while trying to retrieve all these documents.

[Garito]

The frozen app shows up with small amount of huge documents too
To reproduce it save the response of gcloud's documentai of a page with a lot of text and try

[cars10]

Hello @Garito , can you reproduce this with the latest version (1.1.0)?

[Garito]

Yes, I can confirm
It is a matter of a huge doc loaded to memory even in the list view (imagine 10, 100, etc)
If I disable the huge field in the view it goes back to "normal"

[cars10]

Will be fixed in 1.1.1. Field value will be truncated after 200 characters, you can change this in the settings.

[Garito]

A suggestion then:
the copy button should copy the complete doc

[Garito]

Thanks btw