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.