Child Item

/search lists files that do not match the query

As of yesterday June 25, 2019 2:00am GMT+0200 our test suite beeped and shows that the `/search` endpoint outputs results that do not match the query string.

Request body:

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

Request response:

matches: [,…]
0: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_4553450483_7432473521.txt",…}}
1: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_4553450483_3913973871.txt",…}}
2: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_4121529854_5588117075.txt",…}}
3: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_4121529854_4679376563.txt",…}}
4: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_9851551923_3797263296.txt",…}}
5: {match_type: {.tag: "both"}, metadata: {.tag: "file", name: "testprefix_2279819496_7108292884.txt",…}}
...

Environment: There are a lot of old test files in the respective folder. We try to delete them after each test, but sometimes the test suite fails to do so. So it may have something to do with the number of files in the folder. However renaming the folder and working with an empty one does not change the situation. The files are still in the result of the query even after hours of time elapsed for performing indexing on the server side.

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

@offbeata Apologies for the delay. This should be working as expected again now. Please try again and let me know if it is or isn't working properly. Thanks!

All comments

TaylorKrusen

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?

offbeata

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

TaylorKrusen

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!

TaylorKrusen

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.

offbeata

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

TaylorKrusen

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.

Greg-DB

@offbeata Apologies for the delay. This should be working as expected again now. Please try again and let me know if it is or isn't working properly. Thanks!

offbeata

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