github/github-mcp-server · error
updated_field.id: %w
Error message
updated_field.id: %w
What it means
Raised by parseBatchFieldSpec (pkg/github/projects_batch.go:524) when updated_field.id fails validatePositiveInt64. The wrapped cause is one of: 'value must be a number (got string)' for quoted IDs, 'value must be a valid integer' for fractional floats, or 'value must be greater than zero' for 0/negative. This fails the whole request before any item is processed.
Source
Thrown at pkg/github/projects_batch.go:524
}
value, hasValue := input["value"]
if !hasValue {
return spec, fmt.Errorf("updated_field.value is required")
}
spec.value = value
idField, hasID := input["id"]
nameField, hasName := input["name"]
switch {
case hasID && hasName:
return spec, fmt.Errorf("updated_field must set either id or name, not both")
case !hasID && !hasName:
return spec, fmt.Errorf("updated_field requires either id or name")
case hasID:
id, err := validatePositiveInt64(idField)
if err != nil {
return spec, fmt.Errorf("updated_field.id: %w", err)
}
spec.id = id
default:
name, ok := nameField.(string)
if !ok || name == "" {
return spec, fmt.Errorf("updated_field.name must be a non-empty string")
}
spec.name = name
}
return spec, nil
}
func resolveBatchProjectField(ctx context.Context, gqlClient *githubv4.Client, owner, ownerType string, projectNumber int, spec batchFieldSpec) (*ResolvedField, error) {
if spec.name != "" {
return resolveProjectFieldByName(ctx, gqlClient, owner, ownerType, projectNumber, spec.name, "")
}
fields, err := listAllProjectFields(ctx, gqlClient, owner, ownerType, projectNumber)View on GitHub (pinned to 0ea1f775a7)
Solutions
- Send id as an unquoted positive integer taken from a list_project_fields result
- If your config stores IDs as strings, convert to int before building the request
- Verify you are using the field's database ID, not the project ID or project number
- Pre-validate id > 0 and integral before the call
Example fix
// before
{"updated_field": {"id": "MDExOlByb2plY3RmaWVsZDEyMzQ=", "value": "Done"}}
// after
{"updated_field": {"id": 123456, "value": "Done"}}
// or use the name form: {"name": "Status", "value": "Done"} Defensive patterns
Strategy: validation
Validate before calling
if v, ok := spec["id"]; ok {
f, isNum := v.(float64)
if !isNum || f != float64(int64(f)) || int64(f) <= 0 {
return fmt.Errorf("updated_field.id must be a positive integer (got %v)", v)
}
} Type guard
func isPositiveJSONInt(v any) bool { f, ok := v.(float64); return ok && f == float64(int64(f)) && int64(f) > 0 } Prevention
- Store field IDs as numbers, not strings, wherever they are configured
- Confirm the value is the field database ID from list_project_fields — not the project ID or project number
- When in doubt, switch to the name form, which is human-verifiable
When it happens
Trigger: "updated_field": {"id": "123456", "value": ...} (string), {"id": 1.5}, {"id": 0}, {"id": null}, or {"id": -1}. Only unquoted integral numbers survive validateAndConvertToInt64 plus the > 0 check.
Common situations: Field IDs quoted after being stored as strings in config; a zero default when the ID lookup failed; mixing up the project number, project ID ("PVT_..."), and the numeric field database ID — only the last belongs here.
Related errors
- updated_field.name must be a non-empty string
- node_id must be a non-empty string
- item_id: %w
- %s must be a non-empty string
- %s must be a positive integer: %w
AI-assisted analysis of github/github-mcp-server@0ea1f775a7 (2026-08-15).
Data as JSON: /api/errors/a04df35cb1cd9a3a.
Report an issue: GitHub.