Full-text search like in ServiceInsight

[efleming18]

I think it would be extremely useful to have a Search box to search error and archived messages. I know you're able to search for messages in ServiceInsights and "Retry Message" from there, but not everyone has access to the server where ServiceInsights is running. Having the search functionality on ServicePulse, which is exposed behind a VPN via web, would be great.

[WilliamBZA]

@efleming18 Can you expand a bit more on the use case here?

• What would you search on?
• What do you intend to do with the search results?
• How is the current screen not allowing you to find the messages you need?
  • Is it the volume of messages?
  • The volume of groups?
  • Have you toggled between the different groups?
• Is this to find an individual message or a group?

[efleming18]

Hi @WilliamBZA, I would be happy to expand on this!

• Search: Most of our messages that end up in the error queue have some sort of unique identifier on them, usually a GUID, in the exception. Searching by a string, or known specific error message, would also be useful. Even searching for a message by the NSB "messageId", would be great in the beginning.
• For the search results I would want to retry the message if it is in the error queue, and if I find it in the archived messages I would want to unarchive the message and then try to retry it.
• This scenario has come up because a third party, out of our control, has been submitting bad requests to some of our API endpoints. It isn't necessarily causing a problem, but definitely adding hundreds of error messages and not enough of an issue to fix before the next release. Typically, these get archived but of course, in archiving some, the wrong message ended up getting archived. This happened on a Friday, and over the weekend hundreds more messages were archived making it extremely difficult to sift through all the messages to find my 1 message that shouldn't have been archived. I tried changing the filtering, but it did not help much.
• The grouping of the error messages certainly helps this because all of a specific type of message are together, but once they go into the archive it becomes difficult to find them again with many messages being archived. A search that would look through both error messages and archived messages would probably ideal.
• This is to find an individual message

[WilliamBZA]

Thanks @efleming18, this is great feedback. We're planning some pretty big changes to the SP featureset and will definitely use this as input into that plan.

We're currently not happy with the way the search works in SI, so will have to come up with a better approach before we can implement the same functionality in SP.

[efleming18]

Cool. Well I'm certainly excited to see the updates when they become available!

Are there scheduled releases of new features? Just curious.

[Murdos-AU]

Any news or progress on Search? It makes ServicePulse unusable when trying to find a specific value in a message

[WilliamBZA]

No news yet, but this is on our radar.

@Murdos-AU Is your use case the same as Eric's? Meaning, the use case is searching within archived messages for a specific message?

[kbaley]

I had someone asking about this today

[awright18]

I talked to the original author today; he's asking again for this feature.

[ramonsmits]

Asked by visitors at the Techorama booth

[bbrandt]

Additionally, when I search, I'd like to select all that are found (really all, not just displayed on the current page) and delete. Delete all matching is maybe a better description.

Imagine if you have 1 or 2 very important failures but they are mixed within about 1.2 million NServiceBus.ExceptionInfo.Message No handlers could be found for message type messages because you are processing data at a very high rate and huge number of nearly duplicate failures is what happens when a bug creeps into Prod. After you fix the bug, how do you get rid of the noise that it created in your ServicePulse group?

[ramonsmits]

nice suggestion @bbrandt

Delete all matching is maybe a better description.

Usually such tag would use the search query/filter with the timestamp or incremental storage identifier of the last match in the view as a cut-off for the query to ensure new ingested items will not accidentally be deleted.