Use int32 instead of int for CRD integer fields

[ChrisJBurns]

Summary

Six CRD fields use Go's bare int type instead of int32. Go's int is platform-dependent (32-bit on 32-bit systems, 64-bit on 64-bit systems), which creates inconsistent OpenAPI schema generation and violates Kubernetes conventions. Every other port/count field in the codebase already uses int32.

Why this matters:

• int generates type: integer with no format in the OpenAPI spec; int32 generates type: integer, format: int32 — this affects generated client code
• Kubernetes core types universally use int32 for ports and counts (e.g., corev1.ContainerPort, appsv1.DeploymentStatus.Replicas)
• Other fields in the same codebase already use int32: ProxyPort int32, McpPort int32, Replicas *int32, ReadyReplicas int32

Note: MCPGroupStatus.ServerCount and MCPGroupStatus.RemoteProxyCount have the same issue but are tracked separately in #4537.

What to change

1. MCPRegistry types (cmd/thv-operator/api/v1alpha1/mcpregistry_types.go)

Five fields to change:

Line ~296 — MCPRegistryDatabaseConfig.Port:

// Before
Port int `json:"port"`

// After
Port int32 `json:"port"`

Line ~327 — MCPRegistryDatabaseConfig.MaxOpenConns:

// Before
MaxOpenConns int `json:"maxOpenConns,omitempty"`

// After
MaxOpenConns int32 `json:"maxOpenConns,omitempty"`

Line ~333 — MCPRegistryDatabaseConfig.MaxIdleConns:

// Before
MaxIdleConns int `json:"maxIdleConns,omitempty"`

// After
MaxIdleConns int32 `json:"maxIdleConns,omitempty"`

Line ~544 — SyncStatus.AttemptCount:

// Before
AttemptCount int `json:"attemptCount"`

// After
AttemptCount int32 `json:"attemptCount"`

Line ~558 — SyncStatus.ServerCount:

// Before
ServerCount int `json:"serverCount"`

// After
ServerCount int32 `json:"serverCount"`

2. VirtualMCPServer types (cmd/thv-operator/api/v1alpha1/virtualmcpserver_types.go)

One field to change:

Line ~221 — VirtualMCPServerStatus.BackendCount:

// Before
BackendCount int `json:"backendCount,omitempty"`

// After
BackendCount int32 `json:"backendCount,omitempty"`

3. Fix compile errors from type changes

After changing the types, any code that assigns or compares these fields with bare int values will need int32() casts or variable type changes. Search for usages in:

• cmd/thv-operator/controllers/ — controller code that sets status fields (e.g., status.BackendCount = len(...) becomes status.BackendCount = int32(len(...)))
• cmd/thv-operator/pkg/registryapi/ — registry config builders that read Port, MaxOpenConns, MaxIdleConns
• Any test files that construct these structs with literal int values

The compiler will catch all of these — just fix each error with an int32() cast or by changing the source variable type.

4. Regenerate and verify

task gen          # Regenerates CRD manifests with int32 format
task crdref-gen   # Regenerates CRD API docs
task lint-fix     # Fix any lint issues
task lint         # Verify clean
task test         # Unit tests pass
task build        # Builds successfully

After task gen, confirm the OpenAPI schemas in the CRD YAML manifests now include format: int32 for these fields.

Notes

• The JSON wire format is identical — JSON integers don't carry type width, so existing manifests continue to work without changes.
• Existing kubebuilder validation markers (Minimum, Maximum) remain valid on int32 fields.
• Default values (+kubebuilder:default=10 for MaxOpenConns, etc.) remain valid.

Generated with Claude Code

[sharanrajt]

I'd like to work on this.