Conversation
There was a problem hiding this comment.
Pull request overview
Adds QA coverage for Python backend models that define a custom is_model_ready() implementation, validating readiness behavior across sync/async implementations, error cases, and concurrency.
Changes:
- Adds multiple new Python backend test models that implement
is_model_ready()with different behaviors (true/false, exception, non-boolean, coroutine, timeout, decoupled). - Expands
test_model_readiness.pywith a newTestUserDefinedModelReadinessFunctionsuite covering readiness + inference and concurrent ready/infer requests. - Extends
qa/.../model_readiness/test.shto stand up these additional models and run the new unittest suite.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_timeout/model.py | Adds a model whose is_model_ready() intentionally exceeds the default readiness timeout. |
| qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_returns_true_decoupled/model.py | Adds a decoupled streaming model that also defines is_model_ready(). |
| qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_returns_true_decoupled/config.pbtxt | Configures the decoupled streaming model transaction policy and IO. |
| qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_returns_true/model.py | Adds a model with is_model_ready() returning True. |
| qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_returns_false/model.py | Adds a model with is_model_ready() returning False. |
| qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_returns_non_boolean/model.py | Adds a model returning a non-boolean readiness value (negative case). |
| qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_raises_error/model.py | Adds a model whose readiness check raises an exception (negative case). |
| qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_coroutine_returns_true/model.py | Adds a model with an async coroutine is_model_ready(). |
| qa/L0_backend_python/model_readiness/test_model_readiness.py | Adds new unittest coverage for user-defined readiness, including concurrency scenarios. |
| qa/L0_backend_python/model_readiness/test.sh | Updates the QA runner to build/load new models and execute the new test suite. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
qa/L0_backend_python/model_readiness/test_models/is_model_ready_fn_timeout/model.py
Outdated
Show resolved
Hide resolved
whoisj
left a comment
There was a problem hiding this comment.
Approved w/ the assumption you'll react to the CoPilot suggestions.
qa/L0_backend_python/model_readiness/test_models/readiness_coroutine_model.py
Show resolved
Hide resolved
…ck-function-to-tritonpythonmodel
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (3)
qa/L0_backend_python/model_readiness/test.sh:147
- The coroutine model (readiness_coroutine_model.py) does not use the READINESS_FN_RETURN_VALUE parameter that's being set here with value "coroutine". This parameter is only relevant for the regular readiness_model.py. While harmless since the parameter is simply ignored, it could be confusing for maintainers. Consider either passing an empty string or a placeholder value like "unused" to make it clear this parameter doesn't apply to the coroutine model, or add a comment explaining that this parameter is unused for the coroutine variant.
setup_readiness_test_model "is_model_ready_fn_coroutine_returns_true" "coroutine" "0.1"
qa/L0_backend_python/model_readiness/test_model_readiness.py:78
- Consider using
isinstance(result, InferenceServerException)instead oftype(result) == InferenceServerException. While the current pattern exists elsewhere in the codebase (e.g., lifecycle_test.py), usingisinstance()is more Pythonic and properly handles inheritance hierarchies. This would make the code more robust if InferenceServerException is ever subclassed.
if type(result) == InferenceServerException:
qa/L0_backend_python/model_readiness/test_model_readiness.py:231
- The 0.1 second sleep in the thread launch loop adds unnecessary 1.6 seconds of delay (16 iterations * 0.1s) to the test execution time. Consider removing this sleep or moving it inside the thread functions if you need to stagger the requests themselves rather than just their thread starts. If the intent is to avoid overwhelming the server, the delay should be minimal (e.g., 0.01s) or removed entirely since the test is already designed to handle concurrent requests.
time.sleep(0.1)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
...backend_python/model_readiness/test_models/is_model_ready_fn_returns_true_decoupled/model.py
Show resolved
Hide resolved
is_model_ready() in Python backend readiness checksis_ready() in Python backend readiness checks
…ck-function-to-tritonpythonmodel
…-to-tritonpythonmodel' of https://github.com/triton-inference-server/server into spolisetty/tri-466-amazon-agi-add-health-check-function-to-tritonpythonmodel
whoisj
left a comment
There was a problem hiding this comment.
LGTM, thanks for getting through all of this.
What does the PR do?
Adds QA coverage for Python backend feature triton-inference-server/python_backend#430
Changes
is_ready()with different behaviors (true/false, exception, non-boolean, coroutine, timeout, decoupled).test_model_readiness.pywith a newTestUserDefinedModelReadinessFunctionsuite covering readiness + inference and concurrent ready/infer requests.Checklist
<commit_type>: <Title>Commit Type:
Check the conventional commit type
box here and add the label to the github PR.
Related PRs:
triton-inference-server/python_backend#430
Where should the reviewer start?
Test plan:
Caveats:
Background
Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)