Constant ISSUE_BOARD_ITEMS 

pub const ISSUE_BOARD_ITEMS: &str = "query($id:ID!,$first:Int!,$after:String,$nestedFirst:Int!){\n      node(id:$id){\n        ... on Issue{projectItems(first:$first,after:$after){\n          nodes{id project{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}}}\n          pageInfo{hasNextPage endCursor}}}\n      }\n    }";

One issue’s board memberships alone, walked past the page a read of it carried.

The recovery read behind GitHubProjectsSource::resolve_issue: every document above carries a page of Issue.projectItems, and an issue on more boards than that page holds may have this board’s entry past its end. This asks that one issue for its memberships and nothing else — the caller already holds the issue — so an answer of “this board does not hold it” is only ever given about a connection read to exhaustion.

It selects the board item’s id, its project number and the same [board_item_values!] the fragment does, because what it produces is handed to the very same resolver: an issue recovered this way reports the same title, the same status, the same labels and the same qualified id as one whose entry was on the page.

$first rather than $boardItems: this document reads one issue, so nothing multiplies through it and the membership connection can be walked at MAX_PAGE_SIZE — which is what keeps the recovery to one further request for any issue a person really keeps.