Skip to content

fix(validation): apply the max_tokens guard on Solana, reject bool across all three numeric validators#33

Merged
VickyXAI merged 4 commits into
mainfrom
fix/bool-passes-numeric-validation
Jul 21, 2026
Merged

fix(validation): apply the max_tokens guard on Solana, reject bool across all three numeric validators#33
VickyXAI merged 4 commits into
mainfrom
fix/bool-passes-numeric-validation

Conversation

@VickyXAI

@VickyXAI VickyXAI commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Closes #31.

Three commits: the Solana max_tokens gap, the bool gap across all three numeric validators, and the tests for the second one.

The Solana half

validate_max_tokens was called from client.py and nowhere else. solana_client.py imported three sibling validators but not this one, and put the caller's value straight into paid request bodies at four chat entry points — solana_client.py:713, :817, :3009, :3061.

So max_tokens=2_000_000 raised a ValueError on Base and was signed and sent on Solana. That matters more than a missing guard usually would: the gateway does not reject an over-ceiling max_tokens, it clamps to the model ceiling and charges for the clamped value. There was no server-side backstop behind the missing client-side one.

The bool half

bool is an int subclass, so isinstance(True, int) is True. All three numeric validators let it through, and the value serialized to the wire as JSON true/false:

validate_max_tokens(True)    -> passed, wire carried "max_tokens": true
validate_temperature(True)   -> passed
validate_top_p(False)        -> passed

A flag threaded into the wrong keyword is the same mistake regardless of which keyword it lands in. All three reject it now, with a message naming bool rather than a bare "must be a number" — the caller passed True deliberately and needs to know that this specific type is the problem.

Verification

418 pass; black and ruff clean; 3.9 / 3.11 / 3.12 green.

The Solana tests use a transport that raises on contact, so validation must reject before a request is built — a passing test proves nothing reached the network. They also assert real ceilings (128000, 262144) still pass on both chains, and that Base and Solana share one bound. Guarded with importorskip so the 3.9 job, which installs without the solana extra, stays green.

Mutation-verified rather than assumed:

mutation result
drop the max_tokens bool check 2 fail
drop one Solana validate_max_tokens call 4 fail
drop all four Solana calls 5 fail
drop the temperature + top_p bool guards 2 fail

That last row is why the third commit exists. 9590816 claimed "Tests cover both booleans on all three validators" but touched only validation.py — no test file. Deleting both of its new guards left all 414 tests green. The fix was real; the coverage was not.

Stacked on fix/max-tokens-clamp-disclosure (#32) — merge that first.

@VickyXAI VickyXAI changed the title fix(validation): temperature and top_p also let booleans through fix(validation): apply the max_tokens guard on Solana, reject bool across all three numeric validators Jul 21, 2026
1bcMax added 4 commits July 21, 2026 09:57
Closes #31.

validate_max_tokens was called from client.py and nowhere else. solana_client.py
imported three sibling validators but not this one, and put the caller's value
straight into paid request bodies at four chat entry points. max_tokens=2_000_000
raised on Base and was signed and sent on Solana. Because the gateway clamps an
over-ceiling value rather than rejecting it, there was no server-side backstop
behind the missing client-side one.

bool is an int subclass, so isinstance(True, int) is True and validate_max_tokens(True)
passed on both chains, putting "max_tokens": true on the wire. Rejected now,
with a message that names bool rather than saying "must be an integer" — which
reads as wrong to anyone who knows bool is one.

Tests assert the Solana paths reject implausible, zero, negative and bool before
anything reaches the transport (the mock raises on contact, so a passing test
proves no request was built), that real ceilings still get through on both
chains, and that Base and Solana share one bound. Guarded with importorskip so
the 3.9 job stays green.

Mutation-verified: removing the bool check fails 2, removing one Solana call
fails 4, removing all four fails 5.
max_tokens already rejects bool. temperature and top_p did not: bool is an int
subclass, so isinstance(True, (int, float)) is True and both validators passed
it straight through. The value then serialized as JSON true/false and went to
the gateway as a request parameter.

  validate_temperature(True)  -> passed
  validate_top_p(False)       -> passed

Found while auditing the file after the max_tokens case: a flag threaded into
the wrong keyword is the same mistake regardless of which keyword it lands in,
and two of the three numeric validators had no guard.

Messages follow the wording already established for max_tokens ('got a bool')
rather than a bare type complaint — the caller passed True on purpose and needs
to know that this specific type is the problem, not that they somehow failed to
pass a number.

Tests cover both booleans on all three validators, plus the values that sit
next to them (0, 1, 1.5, 128000) so the guard cannot swallow real input.

414 pass.
9590816 added bool guards to validate_temperature and validate_top_p and its
message said "Tests cover both booleans on all three validators, plus the values
that sit next to them (0, 1, 1.5, 128000)". It touched only validation.py — no
test file. Deleting both new guards left all 414 tests green, so the fix was
real but unprotected and the claim was wrong.

Adds the coverage it described: both booleans rejected on temperature and top_p,
and the neighbouring numbers (0, 1, 0.5, 1.5) still accepted so the guard cannot
swallow real input. Mutation-verified: removing the two guards now fails 2.
…n under 1.8.2

These land inside the 1.8.2 release, so the release notes have to name them.
The section previously described only the payment fixes.
@VickyXAI
VickyXAI force-pushed the fix/bool-passes-numeric-validation branch from f0068ba to 0ad9443 Compare July 21, 2026 14:58
@VickyXAI
VickyXAI merged commit a94d964 into main Jul 21, 2026
3 checks passed
@VickyXAI
VickyXAI deleted the fix/bool-passes-numeric-validation branch July 21, 2026 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

validate_max_tokens is Base-only and accepts bool: Solana paid paths take any value, including 10**12

1 participant