{"record":{"id":"7649c80a9fc73bd8","repo":"github/github-mcp-server","slug":"s-exceeds-the-graphql-int-maximum-of-d","errorCode":null,"errorMessage":"%s exceeds the GraphQL Int maximum of %d","messagePattern":"(.+?) exceeds the GraphQL Int maximum of (.+?)","errorType":"validation","errorClass":null,"httpStatus":null,"severity":"error","filePath":"pkg/github/projects_batch.go","lineNumber":479,"sourceCode":"\t}\n\ts, ok := v.(string)\n\tif !ok || s == \"\" {\n\t\treturn \"\", fmt.Errorf(\"%s must be a non-empty string\", key)\n\t}\n\treturn s, nil\n}\n\nfunc intFromEntry(entry map[string]any, key string) (int, error) {\n\tv, ok := entry[key]\n\tif !ok {\n\t\treturn 0, fmt.Errorf(\"missing %s\", key)\n\t}\n\tn, err := validatePositiveInt64(v)\n\tif err != nil {\n\t\treturn 0, fmt.Errorf(\"%s must be a positive integer: %w\", key, err)\n\t}\n\tif n > math.MaxInt32 {\n\t\treturn 0, fmt.Errorf(\"%s exceeds the GraphQL Int maximum of %d\", key, int64(math.MaxInt32))\n\t}\n\treturn int(n), nil\n}\n\nfunc validatePositiveInt64(value any) (int64, error) {\n\tn, err := validateAndConvertToInt64(value)\n\tif err != nil {\n\t\treturn 0, err\n\t}\n\tif n <= 0 {\n\t\treturn 0, fmt.Errorf(\"value must be greater than zero (got %d)\", n)\n\t}\n\treturn n, nil\n}\n\ntype batchFieldSpec struct {\n\tid    int64\n\tname  string","sourceCodeStart":461,"sourceCodeEnd":497,"githubUrl":"https://github.com/github/github-mcp-server/blob/0ea1f775a7c73eff1bd2e25904d01136756bbfe2/pkg/github/projects_batch.go#L461-L497","documentation":"Raised by intFromEntry (pkg/github/projects_batch.go:479) when issue_number is a valid positive int64 but exceeds math.MaxInt32 (2147483647), the maximum for a GraphQL Int on GitHub's API. This guard rejects values that the API itself would refuse, before any network call, and the item fails with 'invalid_item_ref'.","triggerScenarios":"{\"issue_number\": 9999999999} or any integral value above 2147483647. Real GitHub issue numbers are far below this bound, so it almost always indicates corrupted data or a wrong field in the number slot.","commonSituations":"A database ID, timestamp, or phone-like number accidentally mapped into issue_number; sentinel values like 999999999999 used as placeholders; swapped columns where an item ID or project number lands in issue_number.","solutions":["Check the magnitude of the number — real issue numbers are small; if it looks like an ID, move it to item_id or node_id as appropriate","Fix the source mapping that put a large numeric identifier into issue_number","Add a range check (1..2147483647) in your pre-flight validation","Investigate how the value was produced — this error is a symptom of corrupted input, not a GitHub-side limit you will hit legitimately"],"exampleFix":"// before\n{\"item_owner\": \"octo\", \"item_repo\": \"repo\", \"issue_number\": 123456789012}\n// after\n{\"item_owner\": \"octo\", \"item_repo\": \"repo\", \"issue_number\": 1234}","handlingStrategy":"validation","validationCode":"const maxInt32 = 2147483647\nif f, ok := entry[\"issue_number\"].(float64); ok && int64(f) > maxInt32 {\n\treturn fmt.Errorf(\"issue_number %d exceeds GraphQL Int max %d\", int64(f), maxInt32)\n}","typeGuard":"func withinGraphQLIntRange(v any) bool { f, ok := v.(float64); return ok && int64(f) >= 1 && int64(f) <= 2147483647 }","tryCatchPattern":null,"preventionTips":["Treat an out-of-range 'issue number' as a data-mapping bug and trace its origin","Range-check 1..2147483647 in pre-flight validation","Sanity-check magnitudes: real issue numbers are small compared to database IDs and timestamps"],"tags":["github-projects","batch","input-validation","range","issue-ref"],"backgroundTag":null,"analyzedSha":"0ea1f775a7c73eff1bd2e25904d01136756bbfe2","analyzedAt":"2026-08-15T18:10:19.804Z","schemaVersion":2},"datasetVersion":"2026-08-15T22:17:37.221Z"}