Potential fix for code scanning alert no. 3: Incorrect conversion between integer types

[drivebyer]

Potential fix for https://github.com/storbase/redis-operator/security/code-scanning/3

In general, to fix this kind of issue you either (a) parse the integer directly at the target bit size, or (b) add explicit range checks before converting from a larger to a smaller integer type. In Go, using strconv.ParseInt/ParseUint with the correct bit size is preferred to strconv.Atoi when you ultimately need a smaller type.

In this codebase, parseIntField is the common helper that currently returns int via strconv.Atoi. The cleanest fix is to change it to return int32 and to parse using strconv.ParseInt(value, 10, 32). That way, the parsing step itself enforces the 32‑bit range, and all current call sites that immediately cast to int32 (like in cluster.go) can simply use the returned int32 directly, eliminating the unsafe narrowing cast. This does not meaningfully change behavior: if Redis ever reports a number that does not fit in a 32‑bit signed integer, ParseInt will fail and we already propagate an error.

Concretely:

• In internal/infra/redis/admin.go, change parseIntField’s signature from func parseIntField(...)(int, error) to return int32, replace strconv.Atoi by strconv.ParseInt(value, 10, 32), and cast the parsed int64 to int32 on return.
• In internal/infra/redis/cluster.go, update the code building ClusterObservation to remove the redundant int32(...) casts and use the int32 values directly. This addresses the specific flagged sink (int32(slotsAssigned)) and the similar casts for clusterSize and knownNodes.

No new imports are needed: strconv is already imported where used, and we do not need math because we rely on ParseInt’s built-in range checking.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.