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

  1. Send id as an unquoted positive integer taken from a list_project_fields result
  2. If your config stores IDs as strings, convert to int before building the request
  3. Verify you are using the field's database ID, not the project ID or project number
  4. 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

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


AI-assisted analysis of github/github-mcp-server@0ea1f775a7 (2026-08-15). Data as JSON: /api/errors/a04df35cb1cd9a3a. Report an issue: GitHub.