What happens if you move .Track() to just before .GetResult()?

Same issue happens, wherever I put the Track()

Then I would try to remove .Skip(), then .Filter() and then .InField() but still keep .Track() to figure out which filter is causing the issue in .Track() and then report this as a bug to Episerver.

Btw, is the pagination working correctly if you remove .Track()?

I removed all the .Filter(), .Skip() and .InField(), to change the code to the below statement. Still it throws the same exception.

IEnumerable<UnifiedSearchHit> _SearchResults = searchClient.UnifiedSearch().For(queryString)
.Track()
.GetResult(hitSpec, false);

Also, noticed that the issue is not reproducing when I am logged in with EPi Admin login, but it is reproducible when I login via an SAML Authentication account. (We have EPi accounts for Content Authors, but for end-users authentication is implemented via SAML)

And, yes Pagination is working fine.

Hi Nalin,

Can you try this simple query:

var results = searchClient.UnifiedSearchFor(q)
                    .Filter(f => f.MatchType(typeof(FashionProduct)))
                    .Track()
                    .GetResult();

Hope it work,

For more information, refer to this document https://world.episerver.com/documentation/developer-guides/find/NET-Client-API/searching/Unified-search/

/Son Do

Hi Son,

Even this simple query failed. It is throwing the same exception as mentioned above.

Can you try to run reindex job then check again.

Tried it. No success. Still the same exception.

The site doesn't work with simple query, the reason might be your data.

IMO you should create a support ticket. Support guys will call you and get your implementation, your databasse and your index for fixing the issue.

/Son Do

I had exactly this same issue, in the same bit of code, and found that it was actually because the Episerver code tries to allocate a unique ID for the tracking based on this logic (Find 13):

1. If there's no current HTTP Context, use a hash of the MAC address (for example, if this is being called from a console app)
2. If there's no user in the current HTTP Context, use a hash of the Session ID of the current HTTP Context (user not logged on)
3. If there's a user in the current HTTP Context, use a hash of the current user's name in their identity

Point (3) is where it was breaking for me... I was in a web content and authenticated using ASP.NET Identity but was using a custom JWT Token that wasn't adding the Name claim. This meant that HttpContext.Current.User.Identity.Name was null and so it was breaking when trying to hash it.

To fix it, I just added the following line to the code where the JWT Token was being created (this project is generating it's own JWT Tokens in a custom oAuth provider):

  identity.AddClaim(new Claim(ClaimTypes.Name, context.UserName)); // we do this to let Find work - it requires an identity name in order to track statistics

It's almost certain that you've got the same problem - just make sure that the steps 1-3 above are all valid and the code should work!

Thank you Dan,

Adding the Name claim worked like a charm.

The fix for FIND-3741 will solve this issue. The fix will also include null-check.