Refactor listPaginated tests + make README clearer
#312
Conversation
|
(Current CI failures are due to known-flakiness on the integration tests for |
README.md
Outdated
| @@ -945,11 +959,20 @@ console.log(results); | |||
| // usage: { readUnits: 1 } | |||
| // } | |||
|
|
|||
| // Fetch the next page of results | |||
| await index.listPaginated({ | |||
| // Grab the final vector ID matching prefix 'doc1#' using the paginationToken returned by the previous call | |||
There was a problem hiding this comment.
Nit: "Fetch" is a verb we use elsewhere. "Get" might also make sense given the http verb. I'd avoid "Grab"
There was a problem hiding this comment.
Ah okay thanks, I'll change to fetch!
README.md
Outdated
|
|
||
| - When you do not specify a `prefix`, the default prefix is an empty string, which returns all vector IDs | ||
| in your index | ||
| - There is a hard limit of `300` vector IDs if no `limit` is specified. Consequently, if there are fewer than `300` |
There was a problem hiding this comment.
Does it default to 300 or is that the limit? I had thought the default was 100. 🤔
There was a problem hiding this comment.
In the core DB code, the limit is 300. Let me test it out personally and get back to you (maybe the API limits it to 100).
There was a problem hiding this comment.
Ah fantastic catch @austin-denoble ! It is 100 on the API side now. I will change :)
Problem
The core DB previously had a race-condition bug that resulted in pagination tokens being non-deterministically returned to the user when they'd call the
listPaginatedendpoint (not just in the TS client).Solution
The core DB team has fixed this bug. Now that it's fixed, this PR updates previously-commented-out tests + updates the README to be more precise regarding how this method works.
Type of Change
Test Plan
CI passes.