Yeah, well ~300 resources really shouldn’t be enough by itself to trigger systemic pagination failures.
The failed: 4 correlation is much more interesting though. If the consistently failing vector store is also the only one containing failed entries, I wonder if the list/pagination path is hitting some bad state or retry edge case while resolving failed file metadata internally![]()
Hmm.. Especially since:
-
the successful store has zero failed files
-
the failing store consistently has non-zero failed entries
-
and the failures occur during listing rather than upload.
So it might be worth testing by manually removing/recreating only the failed entries (or recreating the store cleanly) to see whether the pagination instability disappears![]()