Two loose ends and a product decision left over from the drive/mounts recency view.
Product decision needed: _rollup_recent_entries collapses a freshly-created directory (e.g. a just-cloned repo) into one folder row in the recency list. But it needs outside activity on at least one side to detect the batch boundary. A mount whose entire visible history is a single batch — the drive opened right after the motivating git clone — has no outside activity, so nothing rolls up at any level and the recency list floods with individual leaf files exactly in the scenario the feature was built for. The effect is cosmetic (the list is limit-capped), but it wants a decision on a single-batch fallback.
Cosmetics (verified present on the branch tip):
Follow-up from the #5400 backend review. Cited findings: 3.3 (the rollup heuristic fails its own motivating single-batch case; the single-batch fallback is a product call) and the flat-view total / count-only sentinel cosmetics noted in 2.2 / 4.8. (The earlier next_cursor-vs-cursor naming point is dropped — the paged listing it referred to was removed from the branch.) The review report is not in the repo, so this summary stands alone.
Two loose ends and a product decision left over from the drive/mounts recency view.
Product decision needed:
_rollup_recent_entriescollapses a freshly-created directory (e.g. a just-cloned repo) into one folder row in the recency list. But it needs outside activity on at least one side to detect the batch boundary. A mount whose entire visible history is a single batch — the drive opened right after the motivatinggit clone— has no outside activity, so nothing rolls up at any level and the recency list floods with individual leaf files exactly in the scenario the feature was built for. The effect is cosmetic (the list is limit-capped), but it wants a decision on a single-batch fallback.Cosmetics (verified present on the branch tip):
limit=0is an undiscoverable count-only sentinel onGET /{mount_id}/files(count_only = limit == 0 and order is None). Give it a discoverable form or document it.totalis computed aslen(files)before the hidden-path filter runs, while the returned list excludes hidden entries — so the count badge and the visible list disagree by the number of hidden/dotfile entries. Computetotalover the same set that is returned, or define the field's meaning explicitly.Follow-up from the #5400 backend review. Cited findings: 3.3 (the rollup heuristic fails its own motivating single-batch case; the single-batch fallback is a product call) and the flat-view
total/ count-only sentinel cosmetics noted in 2.2 / 4.8. (The earliernext_cursor-vs-cursornaming point is dropped — the paged listing it referred to was removed from the branch.) The review report is not in the repo, so this summary stands alone.