Reject bool where a plain int is expected in _is_valid

[NishchayMahor]

What

_is_valid in weaviate/validator.py ends with return isinstance(value, expected). Because bool is a subclass of int, isinstance(True, int) is True, so a bool passes validation wherever a bare int is expected:

_is_valid(int, True)   # -> True  (should be False)

Real call sites hit this — e.g. query.py validates limit / offset / autocut as [int, None]. So:

collection.query.fetch_objects(limit=True)

silently passes validation and sends True (coerced to 1) instead of raising WeaviateInvalidInputError. This is the same class of bug that #2076 reported and #2077 fixed in config.py / util.py (... and not isinstance(x, bool)); this is the unguarded sibling site in the validator.

Fix

Guard the int case at the terminal return, so a bool is rejected where a plain int is expected:

if expected is int and isinstance(value, bool):
    return False
return isinstance(value, expected)

bool-typed expectations (_is_valid(bool, True)) and all other types are unaffected.

Testing

Added a case to the existing parametrized test_validator in test/collection/test_validator.py:

(True, [int], True),   # bool must not validate as int

It fails on main and passes with the fix (verified). The suite is fully offline (no DB/Docker), and the existing (1.0, [int], True) case establishes the same "reject the wrong numeric type" pattern.

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[weaviate-git-bot]

To avoid any confusion in the future about your contribution to Weaviate, we work with a Contributor License Agreement. If you agree, you can simply add a comment to this PR that you agree with the CLA so that we can merge.

beep boop - the Weaviate bot 👋🤖

PS:
Are you already a member of the Weaviate Forum?

[NishchayMahor]

I agree with the CLA.

[eeshsaxena]

This looks correct to me. I traced the call path: _validate_input does any(_is_valid(exp, value) for exp in validate.expected), so for expected=[int] it calls _is_valid(int, value) with a bare int. None of the earlier branches in _is_valid match a plain int (not None, not _ExtraTypes, get_origin(int) is None), so it falls through to return isinstance(value, expected) - and since bool is a subclass of int, isinstance(True, int) is True. So a bool did slip through wherever a bare int is expected, exactly as described.

Two things I checked that make the fix feel well-scoped:

• It guards on expected is int specifically, so the existing expected=[bool] call sites (validating genuine bool params) are untouched - a real bool still validates against [bool]. Good that it doesn't over-reach.
• I grepped the call sites for a reachable Union[int, ...] (the Union branch has the same isinstance(True, int) behaviour), and didn't find one - the int-bearing validations are all list-form like [int, None], which route through this bare-int path. So the narrower fix here is sufficient for the actual call sites.

The added (True, [int], True) parametrize case pins it (expects WeaviateInvalidInputError).

Deferring to the maintainers for the final call.