Summary
When browsing to the Find admin UI in our production admin instance, no data is displayed in any of the individual admin parts. For instance, browsing to Episerver > Find > Overview > Explore shows a spinner and a "Retrieving data" message, but no results are displayed.
However, searching for products on the site succeeds, as does searching for products in the catalog UI (we've configured catalog UI to use find for searching).
Details
Looking at the request made by the find admin UI, we see a request to /episerver/Find/_proxy/_search that returns a 500 error. the POST data is:
{"query":{"query_string":{"query":"*:*"}},"partial_fields":{"partial_source":{"include":"*","exclude":"*$$attachment"}},"facets":{"type":{"terms":{"field":"$type","size":100}}},"size":25}
The EventViewer on the server shows the following error:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 3/15/2018 1:55:09 PM
Event time (UTC): 3/15/2018 6:55:09 PM
Event ID: 8d872657057542d89a99ece041ec6f41
Event sequence: 22
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/2/ROOT-14-131656136125187215
Trust level: Full
Application Virtual Path: /
Application Path: D:\path\to\site\
Machine name: MACHINE_NAME
Process information:
Process ID: 2176
Process name: w3wp.exe
Account name: IIS APPPOOL\App Pool Name
Exception information:
Exception type: HttpRequestException
Exception message: Error while copying content to a stream.
at System.Net.Http.HttpContent.d__44.MoveNext()
The CancellationTokenSource has been disposed.
at System.Threading.CancellationTokenSource.ThrowObjectDisposedException()
at System.Threading.CancellationTokenSource.InternalRegister(Action`1 callback, Object stateForCallback, SynchronizationContext targetSyncContext, ExecutionContext executionContext)
at System.Threading.CancellationToken.Register(Action`1 callback, Object state, Boolean useSynchronizationContext, Boolean useExecutionContext)
at System.Threading.CancellationToken.Register(Action`1 callback, Object state)
at System.Net.Http.WinHttpResponseStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken token)
at System.Net.Http.StreamToStreamCopy.d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Net.Http.HttpContent.d__44.MoveNext()
Request information:
Request URL: https://admin.server.domain:443/epiAdminPath/Find/proxy/_search
Request path: /episerver/Find/proxy/_search
User host address: (omitted)
User: me
Is authenticated: True
Authentication Type: ApplicationCookie
Thread account name: IIS APPPOOL\App Pool Name
Thread information:
Thread ID: 535
Thread account name: IIS APPPOOL\App Pool Name
Is impersonating: False
Stack trace: at System.Net.Http.HttpContent.d__44.MoveNext()
Custom event details:
Other searches in the admin that do not use the Find/proxy api appear to succeed. For example, navigating to EpiAdmin > Find > Configure > Boosting and using the "Preview the boosting effect" feature returns results. This request is a post to https://admin.server.domain/epiesrver/Find/api/editorialboosting/searchwithweights/ with the folowing payload:
{"query":"animal","language":null,"apply_best_bets":false,"weights":{},"apply_synonyms":false,"size":25}
Research
We found this support post, but I don't believe it is the cause of our problem. It mentions that the fix is to add an attribute to httpRuntime in web.config of targetFramework='4.6.1', but I don't believe that targetFramework is a part of the schema for httpRuntime, but rather system.web/compilation. (we already have a targetFramework='4.7.1' on the compilation element)
Versions
We're using
- CMS 11.3.2
- Commerce 11.8.1
- Find and Find.UI 12.7.1
- Find.Commerce 10.1.0
Environments
This is happening in our CI environment and our Production environment, one with a developer and another with a production index. Therefore, I know it's our code or library code that's the problem, and not network or environment problems.