Constant ISSUE 

pub const ISSUE: &str = "query($id:ID!,$first:Int!,$nestedFirst:Int!,$boardItems:Int!,$duplicates:Boolean!){\n      node(id:$id){__typename ...BoardIssue ... on Issue{\n        boards:projectItems(first:$boardItems){nodes{project{id number fields(first:$nestedFirst){nodes{\n          ... on ProjectV2SingleSelectField{__typename id name options{id name}}\n          ... on ProjectV2Field{__typename id name}\n        }pageInfo{hasNextPage}}}}}\n        blockedBy(first:$first){nodes{...Related}pageInfo{hasNextPage endCursor}}\n      }}\n    } fragment BoardIssue on Issue{__typename id number title body url createdAt updatedAt state stateReason(enableDuplicate:$duplicates) repository{nameWithOwner} parent{id} subIssuesSummary{total}\n      labels(first:$nestedFirst){nodes{id name color}pageInfo{hasNextPage}}\n      projectItems(first:$boardItems){nodes{id 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}}";

One issue by its own node id, which is what a qualified id names here — with what a write of it needs and the issue does not carry in board_issue!: the field definitions of the boards it sits on, and the far ends of its blockedBy.

Strongly consistent, unlike the search above: GitHub’s issue search is an index and answers a write made moments ago with the value from before it, and resolving a node id does not.

Why those two ride here and not on the fragment. A copy or an update of an item reads it by its own id, and with them that one read answers everything the write needs: which option ids the board’s Status and Priority fields hold — so no BOARD_FIELDS — and which issues block it, with each one’s kind — so no ISSUE_DEPENDENCIES. On board_issue! they would sit under the hundred-issue pages of SEARCH_ISSUES and SUB_ISSUES, multiplying both documents’ price. Here they sit under one item, and this read is still one point.