Constant RESOLUTION 

pub const RESOLUTION: &str = "query($key:String!){ teams(first:2,filter:{key:{eqIgnoreCase:$key}}){nodes{id states(first:250){nodes{id name type} pageInfo{hasNextPage}}}} projectStatuses(first:250){nodes{id name type position} pageInfo{hasNextPage}} }";

Everything a status write resolves, in one request: the configured team’s id, that team’s workflow states, and the workspace’s project statuses, each with its type.

One document rather than three lookups, because a status write’s cost is counted at Linear’s endpoint on a key every manager of a workspace shares: a source sends this once and holds the answer for its own lifetime (see the ruling on the resolution cache in this crate’s module documentation). Team.states and Query.projectStatuses are each read as one page of Linear’s connection maximum, 250, and refused rather than read short when either says it has more — a team holds a few dozen states at most, and a workspace a few dozen project statuses, so a resolution that does not fit one page is not one this source guesses at — and projectStatuses takes no filter: Linear refuses one outright with Unknown argument "filter" on field "Query.projectStatuses", which is why a project status is matched by name here, locally. position is read for one reason: a project status sources fields --apply creates is placed after the workspace’s last.

teams is read at first:2 and never at Linear’s default page of 50, because Linear scores a connection’s selection once per node its page may hold: at the default, the 250 states asked of each of fifty possible teams scored this document 30905 against Linear’s limit of 10000, and the live journey’s first status write was refused Query too complex. Two rather than one so a key matching more than one team is still seen, and refused, by the exactly-one rule that reads this answer. states and projectStatuses stay at 250, whole or refused, as above: a name a page cut off would read as missing.

Under Linear’s documented model — a property 0.1, an object 1, and a connection’s children multiplied by its first, or 50 without one — the refused document scores 50 × (1 + 0.1 + 250 × (1.3 + 1.1)) + 250 × (1.4 + 1.1) = 30680, and this one 2 × 601.1 + 625 = 1827.2. Linear’s own figures run 225 above the model on both documents it has reported here (30905 for the refused one, 17475 for PROJECTS at 250), and one point more for every node of every connection at every depth — 752 here — still leaves this under 2580, about a quarter of the limit. Like super::MAX_PAGE_SIZE, nothing offline can hold this — complexity appears in no schema — and the live journey is what guards it.