Search results are not displayed when clicking on 'View in ServiceInsight" from ServicePulse

[mauroservienti]

Steps to reproduce

• Open ServiceInsight
  • Manually connect to a ServiceControl instance
  • Make sure the instance is the selected one
• Open ServicePulse connected to a different ServiceControl instance
  • Select a failed message
  • Click on View in ServiceInsight
• ServiceInsight will open (or get to the foreground)
  • Si will add the new connection
  • BUG: the new connection is not selected in the explorer tree view (it's a different bug tracked in Endpoint explorer TreeView selection may not be correct #1212 )
  • SI will perform the search
  • the failed message is briefly displayed in the messages view
  • the messages view is refreshed and all messages are listed

From the second time on, the behavior is correct. To trigger the bug again it's enough to change the ServiceControl selected node in the Endpoint explorer and the bug manifests itself once more.

Expected behavior

ServiceInsight displays the failed message and not all the messages from the recently added ServiceControl connection.

[mauroservienti]

Turns out the problem might be somewhere else. In ServicePulse specifically. ServiceInsight expects the command line search/query to contain the endpoint name to select but ServicePulse is not adding it.

[mauroservienti]

This is a bug in ServicePulse. It'll be fixed by:

• Make sure the built URI contains the endpoint name ServicePulse#1202.

@WojcikMike @ramonsmits, as far as I have understood from the ServiceInsight code the command line parser tries to inspect the incoming URI looking for well-known keys, one of which is the endpoint name. If it doesn't find it, it ignores the issue. When the search is performed though the endpoint name is required. Shall the search throw if the selected endpoint is null?

[mauroservienti]

The problem is due to a concurrency in how the search and the default message loading happens. When SI reacts to an external query request that contains no endpoint it does the following:

• performs the search against the command line identified ServiceControl instance
• the query returns quite fast and results are displayed
• At the same time given that there is no endpoint in the command line arguments the ServiceControl node is selected via code in the Explorer view
• The selection causes a refresh of the messages which is slower than the search, finishes second, and replaces the search results

Particular/ServicePulse#1202 fixes the specific ServicePulse behavior but doesn't fix the command line behavior, which I don't think anyone uses without ServicePulse.