nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

files/search results seem to be too inclusive

Digitalhappy

My application uses files/search (with mode=filename) to find specific marker files with our dropbox structure in order to identify the correct folder to work with.

These marker files have unique names eg ".a00000XXXXXXXXXXXXXXX.sfdb".

(Those are Dropbox for Salesforce folder markers).

Yesterday and for the past 6 months or more, files/search would return only exact matches. In most cases 1 match.

Today files/search seems to be applying some sort of "fuzzy" search and matches more or less anything that looks a bit like what I asked for resulting in responses containing 100

matches.

This is causing problems with my application as now I need to parse all the responses and discard all but an exact match.

Is this an official change to the files/search behaviour?
Is there a way to specifiy exact match only?

Regards

Matt Casey

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Hi Matt, thanks for the report. There isn't a way to force exact matches, but I don't believe there was supposed to be a change to introduce fuzzy matching anyway.

Can you share a sample set of request parameters and the results you're getting back so we can make sure we understand exactly what you're seeing and look into this for you? Thanks in advance!

Digitalhappy

Hi Greg,

I have raised this as ticket with the business support team and provided logs showing the difference in response from files/search from yesterday and today.

I know there isn't an explicit way to force an exact match but prior to today the matches returned from files/search only ever returned a single match when you searched for a filename that existed somewhere in Dropbox.

My use case is to identify folders created by the Dropbox for Salesforce integration. It creates an ".{{SFID}}.sfdb" file in each related folder, where {{SFID}} is the salesforce ID of the related object.

My search params were very simple;

{
"path":"",
"query":"\\.{{SFID}}.sfdb",
"mode":"filename"
}

This gave a simple method to identify folders based on the existence of special marker files.

Today the search is returning "similar" matches and in many cases the similar matches are quite different from what you searched for.

This would be ok if you could be sure that the exact match was ranked the highest in the search results but unfortunately that doesn't appear to be the case.

In many cases the similar - but often quite different - matches appear higher up in the response set. In some cases the similar responses are so numerous that the exact match doesn't appear in the first 100 matches and requires further requests to find the match.

I'm currently trying searches using different search query strings to see if I can reliable return the exact match first.

Greg-DB

Thanks! We'll check the logs in your ticket and look into this.

Greg-DB

I don't have an update on this yet, but this is currently open with engineering. I'll follow up here once I have some news for you.

Greg-DB

This should be fixed now. Please let us know if you're still seeing any issues.

dev1

I think I have fallen foul of this as well. I'm pretty sure up until recently (presumably 3 weeks ago) searching for the filename "ABC.pdf" only returned an exact match. But now it's also matching "ABC blah blah.pdf" which I don't want.

Digitalhappy

I contacted support directly using my business account contact, they confirmed that some users were experiencing the same issue and escalated the issue to their API team.

After a week or so the issue was resolved and now the search behaviour is back to how it used to be for me. I have no idea what they did.

Not knowing if the issue would be resolved, I re-wrote my code to expect multiple results and also changed the search query I was using to find the files.

My particular use-case is searching for marker files to identify individual folders. The markers are all very similar - 15 alphanumeric chars - and all end in the same extension ".sfdb" and there are around 20K of them in our Dropbox.

The new search was returning pretty much any .sfdb file and in most cases the exact match wasn't in the first or even second result set.

The thing I found to give the most consistant results was to not include the file extension in the search query. ie. search for "abcd00000001234" not "abcd00000001234.sfdb".

Removing the extension meant I received just a handful of results with the exact match consistantly being in the first 3 results. So I used that technique with a small limit on the result set (5 or 10) and then parsed the results to find the exact match.

That worked well for me with my particular search requirements. The same might not be true for you.

Greg-DB

@dev1 If you're still seeing unexpected entries like that, please open an API ticket with the details so we can investigate. Thanks!