Skip to main content

parse_include

Function parse_include 

Source
pub fn parse_include(include: &str) -> Result<Vec<Vec<String>>, ParseError>
Expand description

Parse the include parameter into paths, every prefix materialized and sorted by depth.

a.b.c yields a, a.b, a.b.c, sorted so a parent resolves before its child (RestQuery.js:241-257).

include=* is out of scope for 0.2.0 and is an explicit error, not a silently unexpanded response. includeAll requires walking every Pointer and Array field of every result class, and returning bare pointers where a client asked for objects is the kind of difference an SDK turns into a null dereference rather than an error.

The two limits are a deliberate difference from upstream’s defaults, not from upstream. The pin has requestComplexity.includeDepth and requestComplexity.includeCount (Options/Definitions.js:751-762), and both default to -1, meaning unbounded, with master and maintenance exempt. So upstream ships the unbounded configuration, which is the denial of service described below; these limits are fixed and always on instead. Tier 2 under the security carve-out, recorded with its blast radius.

Expanding every prefix means an include of n components produces n paths whose combined component count is n(n+1)/2, and every one of those paths becomes at least one further query in expand_includes. That is why the parameter is bounded before it is expanded rather than after, and why the dedupe borrows from the original string: both keep the work linear in the length of the input.

The values are not upstream’s, which has no non-negative default to copy. They are set where a real include stops and a hostile one begins: a pointer chain deeper than MAX_INCLUDE_DEPTH is already beyond anything an SDK generates, and MAX_INCLUDE_PATHS distinct paths is more than a wide class has fields. A client over either limit is refused by name rather than truncated, because silently dropping an include returns bare pointers where objects were asked for.