pub const SUB_ISSUES: &str = "query($id:ID!,$memberFirst:Int!,$after:String,$nestedFirst:Int!,$boardItems:Int!,$duplicates:Boolean!,$relationshipEvents:[IssueTimelineItemsItemType!]=[BLOCKED_BY_ADDED_EVENT,BLOCKED_BY_REMOVED_EVENT,BLOCKING_ADDED_EVENT,BLOCKING_REMOVED_EVENT,PARENT_ISSUE_ADDED_EVENT,PARENT_ISSUE_REMOVED_EVENT]){\n node(id:$id){__typename ...BoardIssue\n ... on Issue{blockedBy(first:$nestedFirst){nodes{...Related}pageInfo{hasNextPage endCursor}}\n subIssues(first:$memberFirst,after:$after){\n pageInfo{hasNextPage endCursor}\n nodes{__typename ...BoardIssue ... on Issue{\n blockedBy(first:$nestedFirst){nodes{...Related}pageInfo{hasNextPage endCursor}}\n }}\n }}}\n } fragment BoardIssue on Issue{__typename id number title body url createdAt updatedAt state stateReason(enableDuplicate:$duplicates) repository{nameWithOwner} parent{id} subIssuesSummary{total} commentCount:comments{totalCount} relationshipEvents:timelineItems(itemTypes:$relationshipEvents){totalCount}\n labels(first:$nestedFirst){nodes{id name color}pageInfo{hasNextPage}}\n projectItems(first:$boardItems){nodes{id updatedAt project{id number}\n fieldValues(first:$nestedFirst){nodes{\n ... on ProjectV2ItemFieldSingleSelectValue{name field{\n ... on ProjectV2SingleSelectField{id name options{id name}}\n }}\n ... on ProjectV2ItemFieldTextValue{text field{... on ProjectV2Field{id name}}}\n }pageInfo{hasNextPage}}}pageInfo{hasNextPage endCursor}}} fragment Related on Issue{id title body parent{id} subIssuesSummary{total}}";Expand description
One project’s tasks: the sub-issues of the issue that project is, each with a page of what blocks it.
Paged at $memberFirst — MEMBER_PAGE_SIZE, the most rows
one point buys — rather than at $first, because every row carries six connections and
a hundred-row page cost six points to list a project of ten.
The work this costs is the project’s own size. Nothing about it grows as the board gains projects, or as those projects gain tasks.
Why blockedBy rides here and on no other page of issues. What reads a project’s
tasks reads their edges next — project graph draws them, a copy carries them — and
without them here that is one ISSUE_DEPENDENCIES per task, so the requests a graph
costs grow with its tasks rather than with the pages of them. Carried here, a task
blocked by no more than $nestedFirst issues answers its forward edges from this read,
exactly as an ISSUE read of it does, and only one blocked by more is asked again.
It adds a connection under each issue of the page — one rate-limit point per page,
and $nestedFirst nodes per issue — and is kept off SEARCH_ISSUES, whose pages
answer questions that never read an edge.
The project issue itself rides here too, with the page of what blocks it, because the reader of a project’s tasks reads the project next: a copy writing the project reads it and its edges before it writes them. Carried on the request that already names the project, the first page answers that read and the dependency read after it, at the state GitHub answered in this command, rather than spending one more read on an item the cache’s token cannot vouch for whole. Each sub-issue is kept the same way, so a copy’s read of a task this listing carried is answered by it rather than sent again. Only a copy’s read-before-write takes them; every other read by id reads GitHub.