When one creates an devel copy of website, it is normal that SSL certificate of that dev version is copied as well - so it has wrong site url. Certificate may also expire or just get hijacked by crackers in man in the middle attack. Sentry Server cannot grab data from such site, and that's an expected behavior. What's unexpected is that it still shows report from it, just saying "Variable not set properly." on each variable in performance, reporting empty projects list and so on.
Expected behavior would be a message "could not connect due to @message".

Comments

snufkin’s picture

snufkin commented

So basically a per plugin, or per site status should be implemented when connection not available it doesnt show incorrect reports, but an unable to connect message.

rmolotkiewicz’s picture

rmolotkiewicz commented

What I meant is that when Sentry core status is NOT "Client is available and responding.", table row should not contain most module results (as they are misleading), but some kind of failure information should be provided.
Now we have many columns (like 5 our tests and all public ones), so table is wide. It's quite easy to scroll and not see Sentry status, and get mislead. Today it looked like someone broke settings on our dev server, but they were all right - misleading info is worse than lack of any, and tests without data makes no sense anyway. At least some of them.
I see two ways to solve this:
1) Test should either provide some kind of switch "I work / don't work without login" ( like: HTTP availability test does work, Performance status does not). Then, those that does not would not get invoked when rendering table.
2) Force all tests to distinguish if the data they test is wrong or simply missing. This may be sometimes impossible.
In both cases more detailed failure info would be appreciated.

If I read your comment correctly, we mean the same. Sorry for my poor English.

snufkin’s picture

snufkin commented

Your english is very good, no need to apologise.

I would go with option 1 you described, every plugin for every site should first trigger a 'hey is there a client for me'. The reason why this should work per plugin is that each plugin can potentially have its own cron period, so one might meet a 404, then the server gets back online and the other plugins that trigger later work.

I am really happy for these issues popping up, a huge thanks to you guys for working on it and giving me feedback. I cant promise to be able to do coding on this in the next 2 weeks due to exams, but I can review any patches in the meantime.