Feature Request: Fallback to default WP search if/when Algolia usage limit reached/exceeded (search operations)

[KZeni]

Is your feature request related to a problem? Please describe.
Currently, people using an Algolia plan that has a limit on usage (be it a free plan or a spending limit on a paid plan) might find their site search simply breaks once the limit is exceeded without any notice or anything. It just shows the search page without any results when this happens (until the usage is reset for another month, etc.) Then needing the site admin to manually turn off Algolia while the limit has been reached to at least have a working search and then manually turn Algolia back on once it's able to be used again.

Describe the solution you'd like
It appears https://www.algolia.com/doc/rest-api/usage/ could potentially be utilized by this plugin to occasionally check for the current search operation usage (possibly using total_used_search_capacity or similar?) to see if the Algolia application is indeed able to work or not.

Even if pulling individual stats is a bit much (could be nice to surface the usage percentage in the WP dashboard, but that could be a follow-up refinement), it looks like even checking for usage stats via the API of an app that's gone beyond the limit can/will return: {"status":401,"message":"The application is blocked"} for the very basic check of whether it should be working or not to decide if it should use the fallback search.

For a simple example, it might be nice to check daily/hourly via WP's cron for the Algolia app's usage and then if it returned "The application is blocked" or similar (denoting that trying to perform a search won't work) it could/should automatically switch to simply showing the default WordPress-based search (effectively temporarily use the "Do not use Algolia" option this plugin has until it becomes available again.)

As an aside, Algolia already sends out email notifications when this happens so I don't think this plugin also needs to send an email when this threshold is crossed or anything.

I could see this offered as a feature that's seamless & doesn't need a setting (why allow search to be broken; it kinda just makes sense to at least serve up some form of search results when this happens.)

In summary, the basic idea is to have this plugin periodically check for the Algolia app's usage in the background and if it reached the limit or otherwise gives an error it should then just hand off the search results page to WP's default search and disable trying to offer autocomplete (if enabled) to then have it resume normal functionality once the usage API is no longer reporting the limit having been met or similar error. *Extra bonus would then be to surface the current usage within the site admin so they're more aware of if/when this might occur (while this part could certainly be done separately after this, isn't anywhere near as important as the fallback search aspect, and might also need to check to see what date the monthly usage renews on for that app to then check against... but it could be helpful to people while this is looking at utilizing the Usage API.)

Describe alternatives you've considered
Of course, increasing payment would be the quick & easy fix, but that can be prohibitive for those with spending limits needing to be adhered to and it'd be ideal to have Algolia be used when it can while the site's search doesn't break (fallback to WP search) when Algolia can't be used.

I suppose different fallbacks could be considered, but just having WP's built-in search handle it from seems like the cleanest way to go. Also, different methods for checking for usage could be considered, but checking the usage API seems to be the most relevant.

Additional context
I do want to mention that this probably isn't a candidate for a feature behind the Pro version since it's regarding sites needing to keep costs low while working properly so the ones that need it are likely only able to use the free version of this plugin.

[tw2113]

Couple quick thoughts/questions.

1. Are you thinking of this for both InstantSearch based as well as "Backend Search" ?
2. I agree that this shouldn't be a pro feature.

I'm seeing algolia_should_filter_query which we could use to potentially return early with for "Backend search". That may be the best thing to use here, as later on in the pre_get_posts callback that the backend search uses, it fills in this: https://github.com/WebDevStudios/wp-search-with-algolia/blob/main/includes/class-algolia-search.php#L172-L177 to get empty results.

In regards to the instantsearch, I think we'd also want to hook in to algolia_should_override_search_with_instantsearch.

So one callback on both hooks, that somehow checks on current limits/caps, and returns true or false based on that.

[KZeni]

I'm thinking this should probably be checked when using either "Use Algolia with the native WordPress search template" or "Use Algolia with Instantsearch.js" as both will rely on a search operation from Algolia to complete the request (with the "Do not use Algolia" behavior as the momentary fallback to avoid Algolia while the limits have been exceeded.)

Yeah, I trust you know the best hooks to use better than myself so that seems like a fair assessment of things.

Also, I only suggested WP cron for checking the usage API as that would help meter out the API calls to keep it reasonable (hourly? daily? somewhere in-between?) while also allowing that check to happen in the background without slowing down any particular request (that check then saving the status of it having met the limit/error or not [or saved as the actual usage value to prep for potentially showing the usage amount in the dashboard at some point while then having errors effectively be considered as 100% usage] as setting or transient [probably setting/option to avoid the complexity/issues of caching/optimization/etc. plugins that like to clear out transient data more often than not] which those 2 hooks then check against to then determine if it should continue as normal or use the fallback WP-based search). In comparison, checking during the search request would likely hit the Usage API way more often (likely more than what's needed) and would slow down the search results from being shown every time (which, again, seems excessive.) Other approaches can be considered, but using WP cron seemed to make some sense for this.

[tw2113]

Word.

I hadn't started mentally scoping out the status check aspect, just the "we need to use WP native only" aspects. Yes, we're both thinking the exact same scenarios for the settings, just worded slightly differently.

Going to leave the enhancement issue open for any further consideration or anyone wanting to pick it up.

[daveromsey]

I discussed this with @tw2113 and I'm just adding some thoughts/comments:

• Overall, it seems like a great idea to give feedback to site admins and allow for gracefully handling hitting API usage limits.
• Using the Algolia Usage API is a good idea, but the docs indicate that it's only available as part of the Premium plan or as part of the Enterprise plan as an add-on, so it sounds like we won't be able to use it for the free plan. We still might be able to provide some kind of failover and or notice though.
• Not sure how we'll go about testing against a plan that has hit the API usage limits.
• I think providing an option for users to configure the behavior when hitting the API usage limit would be preferred over the plugin deciding what to do.
• As was discussed already, this functionality might not be suitable for the pro version of the plugin, particularly when network-wide indexing is enabled, since that feature requires Algolia to work and there is no native WP alternative for that.

[KZeni]

Ah, I didn't see that Premium tier notice on the Usage API. That being said... running curl -X GET -H "X-Algolia-API-Key:*INSERT API KEY HERE*" -H "X-Algolia-Application-Id: *INSERT APP ID HERE*" --compressed "https://usage.algolia.com/1/usage/total_used_search_capacity?startDate=2023-09-24T00:00:00.000Z&endDate=2023-10-24T23:23:59.999Z" just now (using a test API key & app ID) gave me an output of:

{"total_used_search_capacity":[{"t":1695513600000,"v":0},{"t":1695600000000,"v":0},{"t":1695686400000,"v":0},{"t":1695772800000,"v":0},{"t":1695859200000,"v":0},{"t":1695945600000,"v":0},{"t":1696032000000,"v":0},{"t":1696118400000,"v":0},{"t":1696204800000,"v":0},{"t":1696291200000,"v":0},{"t":1696377600000,"v":0},{"t":1696464000000,"v":0},{"t":1696550400000,"v":0},{"t":1696636800000,"v":0},{"t":1696723200000,"v":0},{"t":1696809600000,"v":0},{"t":1696896000000,"v":0},{"t":1696982400000,"v":0},{"t":1697068800000,"v":0},{"t":1697155200000,"v":0},{"t":1697241600000,"v":0},{"t":1697328000000,"v":0},{"t":1697414400000,"v":0},{"t":1697500800000,"v":0},{"t":1697587200000,"v":0},{"t":1697673600000,"v":1},{"t":1697760000000,"v":0},{"t":1697846400000,"v":0},{"t":1697932800000,"v":0},{"t":1698019200000,"v":0},{"t":1698105600000,"v":1}]}

Meanwhile, it simply returned:

{"status":401,"message":"The application is blocked"}

when the usage went over the monthly limit on a different app ID using effectively that same curl command.

So, I'm wondering if they're just not enforcing that premium tier limitation on the Usage API yet (or if it's just limited to specific methods until Premium which unlocks everything...?) and it could potentially be used in the meantime (it's kinda surprising to see this be returned on a free tier setup given that Premium tier messaging, but it seems to be returning some data on multiple free apps using that method.)

Also, if any of these API endpoints (or similar; it could probably even just try to perform a search request and see if it gets an error instead of search results rather trying to use the Usage API which might become more limited in the future based on that wording in their documentation) are free to use, it seems like it might be able to just check for whether it says the application is blocked or not as it appears to simply shut off any/all access to that app ID once over the limit when it comes to checking to see if it should gracefully fall back to other search methods until it stops returning that API result (rather than needing to pull & display the specific usage statistics [which could still come after the check if it's returning the The application is blocked error for the fallback functionality.])