General approach: avoid narrowing conversions from int64 (parsed with 64‑bit width) to a potentially smaller int without enforcing bounds. We can either (a) change the metric API so it accepts int64, or (b) clamp the int64 value to the valid int range before casting so it cannot overflow, preserving current API signatures. We don’t see the MetricsRecorder interface here, so we must keep its int parameters and add explicit clamping logic at the conversion points.

Best targeted fix: in internal/bootstrap/server.go, introduce a small helper that safely converts int64 to int by clamping to math.MaxInt/math.MinInt. Then use this helper wherever we currently do int(...) on values from the cache (activeAccessTokens, activeRefreshTokens, totalDeviceCodes, pendingDeviceCodes). This ensures that on 32‑bit platforms we never overflow, while on 64‑bit platforms behavior is unchanged. To implement this we need to:

• Add an import of the standard math package in internal/bootstrap/server.go.
• Define a helper, e.g. func safeIntFromInt64(v int64) int.
• Replace:
  • m.SetActiveTokensCount("access", int(activeAccessTokens))
  • m.SetActiveTokensCount("refresh", int(activeRefreshTokens))
  • m.SetActiveDeviceCodesCount(int(totalDeviceCodes), int(pendingDeviceCodes))
    with calls to safeIntFromInt64(...).

No changes are needed in internal/cache/rueidis.go or internal/cache/rueidis_aside.go, because they already parse into int64 correctly. The issue is only at the cast to int in updateGaugeMetricsWithCache.

In general, to fix this type of issue you must avoid narrowing an int64 (parsed with strconv.ParseInt using 64 bits) to a smaller integer type without ensuring the value is within that type’s valid range. You can do this by either (a) parsing directly into the narrower type, or (b) adding explicit upper/lower bound checks before the cast. Here, the problematic conversions are to int purely to feed metric setter methods, and the logical domain of these values (counts) is non‑negative and naturally fits in int64.

The simplest, behavior‑preserving fix is to avoid narrowing at all by changing the metric recording calls to work with int64 instead of int. Assuming changing the interface of metrics.MetricsRecorder is out of scope (and not shown), a safer localized fix is to clamp the int64 counts to the range of int before converting. However, for metrics like “number of tokens/device codes”, it is reasonable and safe to treat negative counts as zero and very large counts as math.MaxInt to avoid overflow. To keep within the provided snippets only, we can convert using int64 → int while guarding with a saturating helper that clamps to [0, math.MaxInt]. We can implement this helper directly inside internal/bootstrap/server.go and use it at the three call sites currently doing int(...).

Concretely in internal/bootstrap/server.go, we will:

• Import the standard math package.
• Add a small helper function, e.g. safeIntFromInt64(v int64) int, that:
  • Treats negative values as 0 (since counts cannot be negative).
  • If v is greater than int64(math.MaxInt), returns math.MaxInt.
  • Otherwise returns int(v).
• Replace:
  • m.SetActiveTokensCount("access", int(activeAccessTokens))
  • m.SetActiveTokensCount("refresh", int(activeRefreshTokens))
  • m.SetActiveDeviceCodesCount(int(totalDeviceCodes), int(pendingDeviceCodes))
    with calls that use safeIntFromInt64(...) instead of raw casts.

This ensures that, regardless of architecture, we never perform an unchecked narrowing conversion from int64 to int, thereby addressing all CodeQL variants that point to these sinks.

In general, to fix this category of issue you should avoid narrowing conversions from a larger integer type (here int64) to a smaller one (int, potentially 32‑bit) without checking that the value fits in the target type’s range. If the API can be changed, an even better solution is to keep using the wider type throughout (e.g., int64 all the way into the metrics recorder), eliminating narrowing conversions entirely.

For this specific case, the cleanest fix without changing existing functionality is to adjust the updateGaugeMetricsWithCache function so that it never converts the 64‑bit counts into plain int. Instead, we should pass int64 to the metrics recorder. Since we cannot modify files we haven’t been shown, the only safe assumption is that we can change how we call the recorder; that implies updating the recorder interface to accept int64. However, we are constrained to only modify the provided snippets. To avoid touching other files, we instead perform a safe, bounds‑checked conversion: before casting int64 to int, compare against math.MaxInt and handle any out‑of‑range values gracefully. This directly addresses the CodeQL alert without changing external behavior in normal ranges.

Concretely, in internal/bootstrap/server.go, we will:

• Import the standard math package.
• Replace the two direct conversions:
  • m.SetActiveDeviceCodesCount(int(totalDeviceCodes), int(pendingDeviceCodes))
  • m.SetActiveTokensCount("access", int(activeAccessTokens))
  • m.SetActiveTokensCount("refresh", int(activeRefreshTokens))
• With helper logic that:
  • Clamps negative values to 0 (since counts should not be negative).
  • If the count exceeds math.MaxInt, records a database query error and logs via gaugeErrorLogger, and then uses math.MaxInt for the metric (or 0, depending on your preference). This preserves functionality for valid ranges and avoids undefined behavior on overflow.

We also ensure all changes stay within internal/bootstrap/server.go as required.

General approach: avoid converting int64 values returned from the cache to a potentially smaller int when recording metrics. Instead, keep using int64 throughout the metrics path, or, if the metrics API truly requires int, add explicit upper‑bound checks before converting.

Best fix here: change the metrics recorder interface (or at least the call sites we see) to accept int64 instead of int for these counts, and pass the int64 values directly without conversion. However, we are not allowed to modify unseen files or interfaces. The safer, minimal change we can make within the shown snippet is to clamp the int64 values to the maximum safe int value before casting. That satisfies CodeQL’s requirement for a bound check and preserves existing behavior for all values in the supported range.

Concretely, in internal/bootstrap/server.go inside updateGaugeMetricsWithCache, we will:

• Import the math package (if not already imported in the full file; within the shown snippet, it is not).
• Before calling m.SetActiveDeviceCodesCount, compute clamped int64 values:
  • safeTotal := totalDeviceCodes and safePending := pendingDeviceCodes.
  • If totalDeviceCodes > int64(math.MaxInt) then set safeTotal = int64(math.MaxInt).
  • Similarly clamp negatives if needed (e.g., treat negative as 0, since counts should not be negative).
• Then convert these clamped values to int when calling SetActiveDeviceCodesCount.

This confines all changes to internal/bootstrap/server.go and ensures that any narrowing conversion from int64 to int is protected by an explicit upper (and lower) bound check.