fix(api): cast replica to int to prevent TypeError on multi-replica launch - #5220
Merged
Merged
Conversation
…aunch
When the frontend submits 'replica' as a string (e.g. '2') in the JSON
body, payload.get() returns the raw string, and list(range('2')) raises
TypeError: 'str' object cannot be interpreted as an integer.
Wrap the value with int() so both integer and string inputs are handled
correctly. This affects both launch_model() and launch_model_by_version().
Co-Authored-By: Claude <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request casts the replica payload parameter to an integer in both the launch_model and launch_model_by_version endpoints. The review comments point out that if replica is explicitly passed as null in the payload, int(None) will raise a TypeError and crash the request with a 500 Internal Server Error. Additionally, if replica is less than 1, it can cause a scheduler crash. The reviewer suggests safely parsing and validating the replica value, raising a 400 Bad Request if it is invalid.
Apply the same int() validation and < 1 guard to launch_model_by_version that was already applied to launch_model. Previously, passing "replica": null or "replica": 0 via the REST API would trigger an unhandled TypeError (500 crash) or a scheduler crash respectively. Now both endpoints return HTTP 400 with a clear error message. Co-Authored-By: Claude <noreply@anthropic.com>
qinxuye
reviewed
Jul 21, 2026
- Add _validate_replica() helper that checks the raw JSON type before int() - Reject bool (True/False) and float (including inf/nan) with 400 - Catch OverflowError in addition to TypeError/ValueError - Apply to both launch_model and launch_model_by_version - Add focused unit tests for all validation paths Addresses review feedback from qinxuye on PR xorbitsai#5220. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix a
TypeError: \x27str\x27 object cannot be interpreted as an integerwhen launching a model withreplica > 1via the REST API.Root cause
The frontend submits
replicaas a string in the JSON body (e.g."replica": "2").payload.get("replica", 1)returns the raw string, andlist(range("2"))raisesTypeError.Single-replica deployments are unaffected because the frontend usually omits the field entirely, so the default
1(int) is used.Fix
Wrap
payload.get("replica", 1)withint()in bothlaunch_model()andlaunch_model_by_version():This handles both integer (
int(1) -> 1) and string (int("2") -> 2) inputs safely.Backward compatibility
✅ Fully compatible —
int(1)is a no-op,int("2")produces the correct integer.🤖 Generated with Claude Code