pub const ISSUE_DEPENDS_ON: &str = "query($id:ID!,$first:Int!,$after:String,$owner:String!,$number:Int!,$boardItems:Int!){\n node(id:$id){__typename\n ... on Issue{body\n blockedBy(first:$first,after:$after){nodes{...Related}pageInfo{hasNextPage endCursor}}\n }\n ... on DraftIssue{id body}}\n draft:node(id:$id){... on DraftIssue{projectV2Items(first:$boardItems){nodes{project{id number}}pageInfo{hasNextPage}}}}\n board:repositoryOwner(login:$owner){... on ProjectV2Owner{projectV2(number:$number){id}}}} fragment Related on Issue{id title body parent{id} subIssuesSummary{total}}";Expand description
What one item depends on: ISSUE_DEPENDENCIES narrowed to blockedBy, so a
dependency read asks GitHub for the one direction it answers. The issue’s body rides
along because its metadata slot is where an edge to another source is recorded — and a
board draft’s body too, with the one board item GitHub links a draft to and, aliased
board, this board’s own id, so a draft’s recorded edges are read off this same answer
and only when that item is this board’s: no draft read and no board read follow it.
The draft’s board item is asked for under a root of its own, aliased draft, rather
than beside its body under node. GitHub counts the type-conditional fragments of
one selection as the largest of them — blockedBy’s 100 alone, where this workspace’s
calculation adds the draft’s 3 — while separate roots are summed by both, so this is
the spelling whose node count GitHub and the calculation agree on. Both price it at
one point; the credentialed lane’s reconciliation is what holds the two to that.