The batch operations walk root and descendants through one helper and write as they go, so the live heap of a folder delete/move/restore/purge is one page of hits (about 7 MB at 100k descendants, flat over folder size) instead of the whole result set.
Path is analyzed into its ancestor prefixes (like path_hierarchy in OpenSearch), so the folder path is a single term shared by every descendant. The descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate no longer expand a prefix or wildcard into one term searcher per descendant, which held gigabytes of live heap on large folders (#1269, #3469). The lookup pages its hits so peak memory stays bounded by the result set.
The tokenizer also emits depth-tagged tokens (1/u, 2/u4, ...) so a geohash facet can be restricted to one precision with TermPrefix instead of one sibling field per precision.
Benchmark BenchmarkSearchResourcesByPath and the memory-bound regression test are adapted from #3485 by n-at-han-k.
Schema version 4 -> 5.
The imaging build decodes the full pixel buffer from the header-declared
dimensions before the existing MaxInputWidth/MaxInputHeight guard runs, so a
tiny crafted file whose header declares huge dimensions forces a multi-GB
allocation and can OOM the worker. Read the header with DecodeConfig and reject
oversized sources before the decode allocates, in both the imaging and vips
builds, and thread the limit through the audio cover-art and geogebra decoders
that decode a second attacker-controlled image.
The recursive tika response lists the file first, then its embedded
resources (cover art, thumbnails, the clip appended to a motion photo).
The loop applied getImage/getPhoto/getLocation/getAudio/getLivePhoto to
every part, so an mp3's embedded cover art leaked a 200x200 image facet
onto the track (and an embedded EXIF image would leak photo/location).
Read those facets from metas[0] only, like the video facet already does;
the loop now only concatenates title/content and detects the motion
photo clip.
Indexing of newly uploaded resources is asynchronous; the search step
slept a fixed 10s and searched once, so under load a just-uploaded file
was missing from the result and the following assertion failed. The
search step now remembers its query, and new eventually-contain steps
re-run the search until the expected entries are present (or the
WaitHelper timeout elapses), then assert as before. contentSearch
scenarios use them for their positive assertions; the exact-count check
runs after the expected entries have appeared.
Property extraction reaches the driveItem asynchronously, so the GET
step previously waited only until any extraction facet key appeared and
a separate step then validated the full schema, which could run on a
partial payload and fail intermittently. The GET and the status check
stay plain steps; a new explicit Then step re-fetches the item until
the response satisfies the expected schema (a partial never matches) or
the WaitHelper timeout elapses.
The legacy OC-Signature path already rejects methods outside
PRE_SIGNED_URL_ALLOWED_HTTP_METHODS, the JWT path did not. A leaked
signed download url could be used for PUT, DELETE, MOVE or PROPFIND
as the signing user for the lifetime of the signature.
$expand=thumbnails was only honored by sharedByMe and sharedWithMe. The
driveItem stat, the children listing and the root children listing now
honor it as well, so a client that lists a folder learns which items have
a preview instead of guessing from the mime type.
The thumbnails are set from the resource info the listing already has, so
a later preview check that needs more than the mime type has a single
place to sit. The two share listings carry driveItems only, they keep
matching on the mime type but share the url building.
Dominik Schmidt