Writers are still saying they are seeing search errors on a regular basis. Particularly, when they are typing into a auto-complete “single-link” field. They say they get around it by pressing the “By Library” button and finding what they need, there.
Do you have any sample code you can provide?
Last error message received: Sorry, your search for “smart” timed out. Please try again or contact support for help. Error ID: e9897abd-0bed-46c7-9512-9377fe2e5409
Thank you @jearle (and sorry, guess that previous hotfix didn’t resolve the issue after all).
Just to clarify… is this when typing inline into the “Vendor” field with the query smart? It only happens in the autocomplete field, not if they do the same search in the “From library”?
The writer that reported it has already left for the day, so I’m not sure. They did say they don’t see the issue when using “From Library”, but I don’t know what field they were using to begin with.
We have a couple of fields that are single-link and I would have though the “Category or Product” field would be the most likely to break based on volume. But, I could be wrong.
Weird, it seems to be the combination of searching two related models at once that causes the timeout (even at the API level). Searching either Category or Product by itself doesn’t cause this error, only the two of them together.
This is the furthest we’ve gotten in diagnosing this issue… thank you for the report and the error ID!! I’ve passed all this along to the devs and will let you know what they find out.
This reminds me of something… back in 2024, another customer had a similar situation with search timeouts in very large models. (Sorry, I can’t seem to find the thread about it)
But as a workaround for them, I made them this example custom search plugin. This is an example search across some 10,000 records. The first field is the default single link field, and the second one below it is the plugin version. The plugin version is much faster.
Unlike the standard Single Link field (which searches through all fields of all relationships), the plugin version re-implements a similar UI, but behind the scenes it:
Lets you define which specific related fields to search through (like just the titles of the related records, not their body text)
Queries each related model independently, in parallel, and then recombines the clientside
As a result, for a similar use case, this plugin is significantly faster than the default single link field (< 1 seconds vs 7+ secs, on 10,000 records).
Is that something you might be interested in trying out in your project? It might help a bit with this situation, and generally make searches across large datasets faster.
If not, no worries… I’ll still let you know what the devs find out about the underlying issue!
Nevermind, lol… I just realized that “other customer” was you yourself from last year, via email I take it there was a reason that plugin didn’t work out for you in the end. No worries, I’ll just wait and let you know what the devs say.
Yeah, sorry, I remember the proposed solution, but I don’t remember why we didn’t implement it. I’ll run it up the chain again and see what they say. But, yeah, hoping for a solution that doesn’t require the dev team to have something else to manage and maintain.
I hear ya. We’re still trying to find the underlying cause of this. It’s hard because this is an extreme edge case for us — you’re the only one who seems to come across it on a regular basis
At least now we have a repeatedly reproducible API call to try to diagnose. I’ll let you know what they find.
Good news! With your help, we were finally able to track down the root issue here (or one of them, at least) and deployed a fix for it this morning. Could you please try again when you get a chance? It shouldn’t time out anymore.
If you still notice any, please do let me know (especially if you get an error ID from it).
Also, if the plugin would still be helpful even without the timeouts, let me know and I can still finish that up for you.