Problem/Motivation
SearchSubscriber events currently react to events no matter the search server. This causes that in a local environment with a local Solr server it attempts to authenticate some requests and fails. A visible symptom of this is that the indexes overview at /admin/config/search/search-api shows error for a valid local solr server.
Steps to reproduce
Having a site hosted in Acquia, clone it locally and spin it up with a local solr server (you could use ddev, docksal or similar to ease this).
Change Solr index to local solr server.
If you visit /admin/config/search/search-api, the valid local solr server will show up as unavailable because of this error.

Proposed resolution
preExecuteRequest and postExecuteRequest should verify the current request is running against Acquia server and only run if that's the case.
Remaining tasks
Provide a patch, review, test and commit.
User interface changes
None
API changes
None
Data model changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3256844-3.1.x-detect-acquia-endpoint_fixed.patch | 1.83 KB | b_sharpe |
| #3 | acquiaEndointCheck.patch | 1.41 KB | fractile81 |
| #2 | 3256844-acquia_search-search-subscriber-only-if-acquia-2.patch | 1.36 KB | kporras07 |
| Screen Shot 2022-01-03 at 18.49.38.png | 23.8 KB | kporras07 |
Issue fork acquia_search-3256844
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
kporras07 commentedAttaching patch.
Comment #3
fractile81 commentedI've run into this same issue today. Here's another patch, this one checking if the endpoint is the same as the client's before continuing with the pre-/post-query code. This likely needs a test added, I'm just not able to do that right now.
Comment #4
b_sharpe commentedSame issue, this definitely needs a fix as it renders local dev useless.
Patch for 3.1.x attached.
Comment #5
b_sharpe commentedOops, wrong order for strpos :) Fixed.
Comment #8
japerryClosing as I don't believe this is an issue anymore. Commit 6c0bf94b changed the check to look for the Acquia Class specifically.
Comment #9
nsciaccaNot sure this should be closed just yet.
I am still experiencing this with my local Docksal setup in the 3.1.0 release as well as the current dev (b8918a2c). Disabling the module or applying the patch from the merge request "3256844-non-acquia-search-subscriber" fixed it.
The error thrown was: "Error while checking server index status: Solr endpoint http://solr:8983/ internal Solr server error (code: 0, body: , message: Solr HTTP error: Authentication of search content failed url: )."
Comment #10
nsciaccaRetracting my comment above. Using version 3.1.3 and this no longer is an issue.