Filtering by Plugin no longer returns results

[ClintWoods]

Problem: filtering by plugin after Wednesday, January 13th 2021 (for us) no longer returns any records. Example: View of all trace logs

Using filter: 1) Select plugin 2) Specify a plugin from the drop down 3) Click Retrieve Logs No records get returned.

What we noticed changed: 1) The TypeName value is much more verbose now 2) The “Message Block” section of the plugintracelog form no longer shows our Trace statements. This probably has nothing to do with the filter problem, but it does indicate a change, probably from the MSFT side.

Before 1/13:

After 1/13:

[rappen]

Thanks @ClintWoods - now that I see this, I realize I have noticed the change too. It definitely seems MS has pushed two changes here:

1. Fully qualified assembly name is included in the typename column
2. If the execution throws an exception, nothing traced will be available in the messageblock, it can only be found at the end of the exception block.

Perhaps @JimDaly has any comments to this?

[JimDaly]

That doesn't look right. I'm not so concerned about the TypeName value being more verbose. Should I be? But the fact that traces aren't being written to the message block seems a serious issue. I've alerted the dev team to check it out.

[JimDaly]

But as always - Opening up a support case is the best first step for something like this.

[rappen]

Can I open a support ticket to say "your change broke my tool"? 😉 The underlying issue here of making the typename more verbose is that the filtering possibilities allow for specifying several plugintypes (including * wildcards) separated by comma, and the new plugintypes returned include lots of commas within what used to be the fully qualified class name (the plugin type!) and now includes classname, assembly name, version, culture, token. So the query performed by PTV is something like:

<fetch>
  <entity name='plugintracelog' >
    <attribute name='correlationid' />
    <attribute name='performanceexecutionstarttime' />
    <attribute name='operationtype' />
    <attribute name='messagename' />
    <attribute name='plugintracelogid' />
    <attribute name='primaryentity' />
    <attribute name='exceptiondetails' />
    <attribute name='messageblock' />
    <attribute name='performanceexecutionduration' />
    <attribute name='createdon' />
    <attribute name='typename' />
    <attribute name='depth' />
    <attribute name='mode' />
    <attribute name='requestid' />
    <filter type='and' >
      <filter type='or' >
        <condition attribute='typename' operator='eq' value='CRMK.xxxx.Synchronization.SetNextSyncTime' />
        <condition attribute='typename' operator='eq' value='CRMK.xxxx.Synchronization' />
        <condition attribute='typename' operator='eq' value='Version=1.0.0.32' />
        <condition attribute='typename' operator='eq' value='Culture=neutral' />
        <condition attribute='typename' operator='eq' value='PublicKeyToken=e7cab53c0186a699' />
      </filter>
    </filter>
    <order attribute='performanceexecutionstarttime' descending='true' />
    <order attribute='correlationid' descending='false' />
    <order attribute='depth' descending='true' />
    <link-entity name='sdkmessageprocessingstep' to='pluginstepid' from='sdkmessageprocessingstepid' link-type='outer' alias='step' >
      <attribute name='name' />
      <attribute name='rank' />
      <attribute name='stage' />
    </link-entity>
  </entity>
</fetch>

...which of course will render 0 hits.

So it would be good to know if this is something temporary that sneaked out, or a deliberate change to stay this way. Might there possibly even be something to read about it somewhere...? (doubting that, since it is a very semi-internal change).

[ClintWoods]

Yes @JimDaly, the type name isn't even an annoyance IMO. I was just noting that there was a change and then the filter stopped working. This particular client of mine uses the tool extensively, so you can be proud of that @rappen! It's "production". LOL.

Just curious... wouldn't "begins with" work better in the Fetch? Thanks for jumping right into this. We appreciate it.

[rappen]

@ClintWoods New release with new option to show FQN is now available with version 1.2021.1.1. Feel free to get back with any comments / requests! And yes, I am proud! 😉

The resulting fetchxml you see above is due to PTV thinks the user wants to filter by multiple different plugins - the comma in the FQN does that.... I'm now handling it in a better way, I think 😀

[JimDaly]

@rappen Calling support to say 'you broke my tool' is perfectly legitimate to me. We shouldn't push out changes like this without consideration and announcement. But isn't the additional data more useful? Seems like you have adapted already?

The more concerning issue to me is that the data in the message block is missing. Devs tell me they found the problem and have Pushed a PR to fix. Still waiting to know when that will take effect. Thanks for letting me know.

[rappen]

Thanks @JimDaly ! 🙏 Yes, I adapted PTV to handle this longer plugintype and pushed a new version.

[ClintWoods]

Hey @rappen, I don't think that quite did it. I updated the tool at the client site and got the same results.

[rappen]

Hm... Curious about your step by step. This is how I do: https://www.screencast.com/t/cfixCPceWs If you make sure the Plugin filter field is empty, and then add filter by plugin, does it still show the FQN in the filter text box? Note that the text in the filter box should be the "simple" class name (everything before the first comma) followed by an asterisk as wildcard.

Also is this checked or unchecked?