Results count inconsistent every time I refresh

[mikezimm]

Version used
4.3

Describe the bug
When I have the results unfiltered on the page and refresh, the "results" count is different.
This is a controlled test meaning no items are being added to the library and I also found that the count varies up and down seemingly randomly.

See screenshots to see what I'm referring to... The Site Contents page shows 5394 items total for my library..
After refreshing over and over... these are the results I get in random testing (in order they happened)
5208, 5172, 5207, 5392, 5207, 5392, 5265, 5217, 5217, 5265, 5168

What I do find interesting after doing that test, is that I see some numbers coming up twice which seems rather unlikely given the odds. I could not really find a pattern though since it does go up and down.

To Reproduce

1. Installed the latest sppkg yesterday.
2. Setup library, site columns, managed meta yah dah yah dah yah dah :)
3. Created a really big library with lots of items
4. Added results and filter on the page (filter with just the * filter)
5. Refreshed the page a bunch of times ( about 5 second delay between each one)

Expected behavior
The unfiltered results count should show a consistent number. I get that a search crawl could always be happening which may impact the numbers. But if nothing was added during a period of time then the number should be stable and consistent.

Screenshots

[FranckyC]

Hi @mikezimm, the result count is an estimation given by the SharePoint search engine especially for large results set so this is the default behavior and not a bug. If you test with a smaller results set, the count should be consistent.

[mikezimm]

Small update ( the plot thickens )...
This may be related to Search itself, limitations with search on large lists >5k items? or something else...

But if I search for a word in the file name it displays lots of those files.
BUT I'm not sure why the result count is always lower than the actual number (I think at least because my test library is large intentionally).

But this is how I am finding this out.
I have a macro that can create 1000's of files with different names by keywords. Each keyword goes into the file name.
I used keywords that would not possibly found in search in any other place except the filename.

I search for "Birch" in the search webpart and I get 532 results give or take if I re-run the search.
I also noticed that when I press the "Next Page", the total results jumps up and down just like if I were to try a new search.

I compare this to a webpart I recently created to be able to assess large libraries by doing paged get until there's nothing more to get.

In my webpart, I know I'm getting the entire library because the count does match Site Contents item count 5394.
I also get the same result count (550) every time I do a search for that rather unique keyword.

I'm stumped why it is doing this and would appreciate any insights.

[mikezimm]

@FranckyC , thanks for the answer, I just saw it after my follow-up since I probably started that before your message.

Do you know off hand how it handles the results in large lists?
For instance, will it work with an 50k file count library without hard-coding any preset filters in the settings?

I'm looking at using the refiners so that the end result should always be well under 5k.

Thanks

[wobba]

@mikezimm this is internal logic in Microsoft Search and nothing we can control nor guess how it will work for different scenarios.

[mikezimm]

@wobba , @FranckyC , Would it be possible in the next update to add a title prop over the results saying something like:
"Results are estimated based on SharePoint search and may not be precise, especially on large lists".

That would be an easy improvement so that at least on hover (or a tool tip) people know something isn't broken.

Regards,
Mike

[wobba]

@mikezimm we won't do that - but you can modify the template yourself and add it. Pick the template you want to use, then click the {} button and it will copy the current template used into the custom template editor.

[mikezimm]

@wobba , well that was easy... Thanks!