SNOW-3324331: client_prefetch_threads validation can bypass the lower bound due to ordering of casting and bounds checks

[abdulselamadillmohammed]

While looking at _validate_client_prefetch_threads() in src/snowflake/connector/connection.py, I noticed that bounds checking is performed before the value is converted to an integer, and then the value is unconditionally reassigned using int(self.client_prefetch_threads) afterward.

Because of this ordering, fractional values between 0 and 1 can bypass the lower-bound check.

For example, if 0.5 is provided:

• The bounds check evaluates 0.5 <= 0 as false, so no correction is applied
• The value is then converted using int(0.5), which results in 0
• The final stored value becomes 0, even though the intended minimum is 1

In practice, this can happen when values come from configuration files, environment variables, or computed expressions (for example, scaling based on CPU count), where non-integer values may be passed unintentionally.

The issue is that conversion and validation are happening in the wrong order, and the value is reassigned after the bounds checks have already run. A more robust approach would be to read the raw value once, convert it once, then apply bounds checks before storing the final result.

I’d be happy to open a PR with a fix and accompanying tests if this approach sounds reasonable.

[sfc-gh-sghosh]

Hello @abdulselamadillmohammed ,

Thanks for raising the concern.

Yes, the logic is incorrect; it should have been casted first to int.
The problematic line is self._client_prefetch_threads = int(self.client_prefetch_threads)

existing code:
     def _validate_client_prefetch_threads(self) -> int:
          if self.client_prefetch_threads <= 0:
              self._client_prefetch_threads = 1
          elif self.client_prefetch_threads > MAX_CLIENT_PREFETCH_THREADS:
              self._client_prefetch_threads = MAX_CLIENT_PREFETCH_THREADS
          self._client_prefetch_threads = int(self.client_prefetch_threads)
          return self.client_prefetch_threads

But the data type for client_prefetch_threads is int, the value is between 1 and 10, so float values should not be passed, so ideally 0.5 is not a correct value to be passed as client_prefetch_threads, it should be always between 1 and 10. We are throwing warning if its float value. Expected usage is always integer — client_prefetch_threads is designed to accept values 1–10 as integers. No Snowflake-side mechanism produces a float for this parameter.

[abdulselamadillmohammed]

Thank you @sfc-gh-sghosh , that makes sense regarding the intended contract.

What I was trying to point out is a bit narrower since _validate_client_prefetch_threads() does not seem to consistently enforce the lower bound when an unexpected client-side value reaches that code path. I thought that is also why the method currently includes the lower-bound check in the first place.

I also believe the warning for unexpected types only happens when validate_default_parameters=True, otherwise the value may still be accepted and then normalized in an unintended way. This is more of an enhancement since the clamping is additional but I can imagine cases where validate_default_parameters=False and invalid input is passed in which case might be difficult to debug. If I’m missing something in that flow, please let me know.

[abdulselamadillmohammed]

Hi @sfc-gh-sghosh ,

After a second examination of connection.py, I noticed a slightly different case here that seems independent of passing a float.

Even with an integer input, client_prefetch_threads=0 appears to normalize to the default value instead of the lower bound.

What I mean is that:

• client_prefetch_threads is declared as an int connection parameter
• the property returns DEFAULT_CLIENT_PREFETCH_THREADS whenever _client_prefetch_threads is falsy
• _validate_client_prefetch_threads() reads back through that property

So if 0 is passed:

1. _client_prefetch_threads is set to 0
2. reading self.client_prefetch_threads returns the default value (4) because 0 is falsy
3. the lower-bound check then sees 4 <= 0 as false
4. the final stored value becomes 4, not 1

That seems a bit inconsistent with the validator’s current intent, since negative values clamp to 1 and values above the max clamp to 10, but 0 appears to fall back to the default instead.

This seems a bit more concrete than the float case as an integer value of 0 doesn't allow lower bound logic to kick in because the validation reads through the property first, which falls back to the default instead of checking the raw stored value directly.

If I’m misunderstanding the intended behavior for 0 here, please let me know.

[sfc-gh-sghosh]

Hi @abdulselamadillmohammed ,

In practice, can 0.5 ever reach _validate_client_prefetch_threads? Almost never. Here's why:

Path 1: Connection construction (connect())

    "client_prefetch_threads": (4, int),  # DEFAULT_CONFIGURATION

  The type is declared as int. If a user passes a float:

    snowflake.connector.connect(client_prefetch_threads=0.5)

  The type validation in __init__ checks isinstance(0.5, int) → False → raises error before validator is called.

Path 2: Server override via _update_parameters()

  The server sends PARAMETER_CLIENT_PREFETCH_THREADS as a session parameter — always an integer (e.g., 4, 8). The server would never send 0.5 for a thread count.

Path 3: Direct setter

conn.client_prefetch_threads = 0.5  # no type check here

This is the only real path where a float reaches the validator. But this would be a user programming mistake.

So, logically float is not allowed as per the documentation as well, the value is between 4 and 10

  DEFAULT_CLIENT_PREFETCH_THREADS = 4
  MAX_CLIENT_PREFETCH_THREADS = 10
  "client_prefetch_threads": (4, int),  # in DEFAULT_CONFIGURATION

So if you want you can raise a PR but it will be of lower priority.