/search lists files that do not match the query

Hi! 

Thanks for the detail. I'm looking into it.

Can you confirm whether the tests were running correctly in the past? Did they start failing without any changes being made to the code? 

Hey Taylor,

yes I can confirm that. Our network test suite runs five times each night and we had five successful runs on the 24th and five failing runs for the same commit on the 25th with the respective test against your /search API failing as described above. What may have changed however between the runs is the contents of the Dropbox account that we use for testing.

Greetings
Stefan

Hi Stefan!

Apologies for the delay. I was able to repro the issue and have filed a bug with engineering. I'll keep you in the loop when I hear back. 

Thank you for letting us know!

Stefan, is this behavior having an impact on your production application, too? 

I don't have full context of the decision, but learned that this is a change in the default behavior of the endpoint. 
In the 'Parameters' section of the file /search endpoint docs: 

query String The string to search for. The search string is split on spaces into multiple tokens. For file name searching, the last token is used for prefix matching (i.e. "bat c" matches "bat cave" but not "batman car").

Basically, the `query` parameter doesn't guarantee a substring match. The docs could be a little clearer here.

Hey Taylor,

you are right the documentation does not mention a full substring match. I my case however I leverage prefix matching on the filenames as stated by the documentation: 'the last token is used for prefix matching'. Since I only give one token in the query string this should match prefix of the file name right?

This may affect the production app as we use the /search api to discover existing accounts for our application in the storage. I have a workaround in place that checks manually if the response is really a prefix match.

I tested again manually and the issue is still present in the Dropbox that I use for integration testing. Worse, the call seems to ignore the path parameter, too. Or is the path matched by prefix too? Documentation says "The path in the user's Dropbox to search. Should probably be a folder."

Request body:

{path: "/tests", query: "testprefix_8753399257_", mode: "filename"}

Response (abbr.):

matches: [,…]
0: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_8753399257_7597581443.txt",…}}
  match_type: {.tag: "both"}
  metadata: {.tag: "file", name: "testprefix_8753399257_7597581443.txt",…}
  .tag: "file"
  client_modified: "2019-06-26T23:23:28Z"
  content_hash: "4b3b3d7dfd0b9e520d6c0c60a6975ef8dcbe35e200b6ea9ee19a9b3e7095eb9c"
  id: "id:MZOmls7LXUAAAAAAAAEEdA"
  is_downloadable: true
  name: "testprefix_8753399257_7597581443.txt"
  path_display: "/tests/testprefix_8753399257_7597581443.txt"
  path_lower: "/tests/testprefix_8753399257_7597581443.txt"
  rev: "daea447b067c3"
  server_modified: "2019-06-26T23:23:28Z"
  size: 36
1: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_8753399257_1141835041.txt",…}}
2: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_9163371511_8050760243.txt",…}}
3: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_9163371511_6853213962.txt",…}}
4: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_4121529854_5588117075.txt",…}}
5: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_4121529854_4679376563.txt",…}}
6: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_9851551923_3797263296.txt",…}}
  match_type: {.tag: "both"}
  metadata: {.tag: "file", name: "testprefix_9851551923_3797263296.txt",…}
  .tag: "file"
  client_modified: "2019-06-25T23:11:01Z"
  content_hash: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
   id: "id:MZOmls7LXUAAAAAAAAAGzQ"
  is_downloadable: true
  name: "testprefix_9851551923_3797263296.txt"
  path_display: "/tests many files/testprefix_9851551923_3797263296.txt"
  path_lower: "/tests many files/testprefix_9851551923_3797263296.txt"
  rev: "d94ba47b067c3"
  server_modified: "2019-06-25T23:11:23Z"
  size: 0
...

Greetings
Stefan

Thanks for the detailed info and logs, Stefan. I added it to the discussion with engineering. 

I would interpret the docs in a similar way for this endpoint. 

I'll let you know when I get new information. Thanks again for the detail and concise explanations.

Hey Greg and Taylor, it seems to be fixed, thank you very much.