feat: integrate Basilica SDK 0.19.0 metadata API, remove spot-check verification#41
feat: integrate Basilica SDK 0.19.0 metadata API, remove spot-check verification#41
Conversation
📝 WalkthroughWalkthroughThis PR removes the spot-check model verification system (deletion of verification.py module, executor config fields, and worker methods) and replaces it with a deployment health check system. Documentation is updated to reflect the shift, new CLI status command is added, and the Basilica SDK dependency is bumped to 0.19.0. Changes
Sequence Diagram(s)sequenceDiagram
actor Scheduler
participant HealthCheck as check_deployment_health
participant BasilicaClient
participant Miner as Deployment
Scheduler->>HealthCheck: check_deployment_health(miners, timeout)
loop For each miner
HealthCheck->>BasilicaClient: query_deployment_metadata(deployment_id, timeout)
BasilicaClient->>Miner: GET metadata
Miner-->>BasilicaClient: deployment state + replicas info
BasilicaClient-->>HealthCheck: metadata (or timeout/error)
alt State is Active/running AND ready replicas > 0
HealthCheck->>HealthCheck: Mark as healthy
else State invalid OR no ready replicas OR query failed
HealthCheck->>HealthCheck: Mark as unhealthy (log reason)
end
end
HealthCheck-->>Scheduler: (healthy_miners[], unhealthy_miners[])
alt healthy_miners is empty
Scheduler->>Scheduler: Fail evaluation cycle
else healthy_miners exists
Scheduler->>Scheduler: Filter tasks to healthy_miners only
Scheduler->>Scheduler: Continue evaluation cycle
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Fix all issues with AI agents
In `@docs/backend-guide.md`:
- Around line 164-174: The docs currently say miners not in a `running` state
are excluded but the scheduler's health check (see health.py which treats both
"Active" and "running" as healthy) accepts both values; update the
backend-guide.md table/paragraph to mention that healthy deployment states
include both "Active" and "running" (or explicitly state which is canonical) so
the documentation matches the behavior in kinitro/scheduler/health.py.
In `@docs/miner-guide.md`:
- Around line 303-314: The fenced code block containing the sample CLI output
for "DEPLOYMENT STATUS" should include a language specifier to satisfy the MD040
linter; update the opening fence from ``` to ```text (and keep the closing fence
as ```) so the block is treated as plain text—locate the block that starts with
the "==================================================" / "DEPLOYMENT STATUS"
sample and add the `text` specifier to the opening backticks.
- Around line 308-316: Update the docs text to state that deployments are
considered healthy when their state is either "Active" or "running" and they
have at least one ready replica, and adjust the example/error wording to remove
the conflicting "expected 'Active'" phrasing; this should mirror the scheduler
health-check behavior implemented in kinitro.scheduler.health so the
documentation and the scheduler (health-check logic) consistently report that
both "Active" and "running" are valid healthy states with ready_replicas >= 1.
In `@kinitro/scheduler/health.py`:
- Around line 32-34: The code currently accepts both "Active" and "running"
(state = getattr(meta, "state", None) and if state not in ("Active",
"running")), but the docstring only mentions "running" and the error message
says expected 'Active'; make them consistent by choosing the canonical accepted
state(s) and updating all three places: the accepted tuple in the state check
(keep or remove "Active"), the unhealthy reason string (reflect the exact
accepted values, e.g., "expected 'running'" or "expected one of
('Active','running')"), and the function/class docstring to list the same
accepted state(s); update references to the state variable and meta accordingly
so the code, message, and docstring are aligned.
- Around line 22-26: The code calls client.get_public_deployment_metadata_async
(and elsewhere get_public_deployment_metadata) which is not in the documented
BasilicaClient API and basilica-sdk 0.19.0 is not on PyPI; verify the installed
basilica-sdk version and replace these calls with the documented methods (e.g.,
client.get_deployment_async or client.get_deployment) or implement a
compatibility wrapper that falls back to get_deployment/get_deployment_async;
update health.py to await the documented async method (or call the sync method
inside a thread if only sync exists) and update deploy.py similarly, and add a
version check or comment noting the required basilica-sdk version.
In `@pyproject.toml`:
- Line 40: The pyproject dependency line currently pins "basilica-sdk==0.19.0"
which does not exist on PyPI; update that dependency declaration to
"basilica-sdk==0.17.0" (the latest available) so installation succeeds—locate
the line containing the string "basilica-sdk==0.19.0" and replace the version
with 0.17.0.
🧹 Nitpick comments (5)
kinitro/cli/miner/deploy.py (1)
184-190: Consider extracting shared enrollment logic.The metadata enrollment block here (lines 184–189) is duplicated almost verbatim at lines 449–454 in
miner_deploy. A small helper like_try_enroll_metadata(client, name)would keep both paths in sync.♻️ Suggested helper
+def _try_enroll_metadata(client: BasilicaClient, deployment_name: str) -> None: + """Enroll deployment in public metadata API (non-fatal).""" + try: + client.enroll_metadata(deployment_name, True) + typer.echo(" Public metadata enrolled") + except Exception as e: + typer.echo(f" Warning: metadata enrollment failed: {e}", err=True)tests/unit/test_health.py (1)
128-142: Timeout test relies on wall-clock sleep — may be flaky in slow CI environments.
asyncio.sleep(10)paired withtimeout=0.1should work in practice, but under heavy CI load the entire coroutine might not even get scheduled before the timeout fires, or conversely the test runner itself could stall. Consider reducing the sleep to something like1.0(still >>0.1) to keep the margin without an unnecessarily large gap. This is a minor robustness concern.tests/unit/test_miner_status.py (3)
31-47: Consider asserting the deployment ID passed to the SDK.The test validates the output formatting but doesn't verify that
get_public_deployment_metadatawas called with the correct deployment name. Adding this assertion would catch regressions where the CLI passes the wrong argument to the SDK.Suggested addition after line 47
assert "v1.0" in result.output + mock_client.get_public_deployment_metadata.assert_called_once_with("my-deployment")
49-60: Same here — assert the deployment ID in the error path.Verifying the argument ensures the CLI correctly forwards the user-supplied deployment name even in the error case.
Suggested addition after line 60
assert "bad-deployment" in result.output + mock_client.get_public_deployment_metadata.assert_called_once_with("bad-deployment")
12-25: Duplicate_make_metadatahelper across test files.This file and
tests/unit/test_health.pyboth define_make_metadatawith overlapping but different fields. While the two serve different purposes (CLI display vs. health check), consider extracting a shared factory into atests/conftest.pyortests/factories.pymodule if the metadata mock shape grows further.
docs/backend-guide.md
Outdated
| | Environment Variable | Default | Description | | ||
| | --------------------------------------------------- | ------- | -------------------------------------------------- | | ||
| | `KINITRO_SCHEDULER_PARETO_TEMPERATURE` | `1.0` | Softmax temperature for weight conversion | | ||
| | `KINITRO_SCHEDULER_TASK_STALE_THRESHOLD_SECONDS` | `900` | Time after which assigned tasks become stale | | ||
| | `KINITRO_SCHEDULER_CYCLE_TIMEOUT_SECONDS` | `7200` | Maximum time to wait for cycle completion | | ||
| | `KINITRO_SCHEDULER_BACKEND_PRIVATE_KEY` | `null` | X25519 private key (hex) for endpoint decrypt | | ||
| | `KINITRO_SCHEDULER_BACKEND_PRIVATE_KEY_FILE` | `null` | Path to backend private key file | | ||
| | `KINITRO_SCHEDULER_DEPLOYMENT_HEALTH_CHECK_ENABLED` | `true` | Check deployment health before creating tasks | | ||
| | `KINITRO_SCHEDULER_DEPLOYMENT_HEALTH_CHECK_TIMEOUT` | `30.0` | Timeout per deployment metadata query (seconds) | | ||
|
|
||
| **Deployment Health Checks:** When enabled (the default), the scheduler queries the Basilica public metadata API for each miner's deployment before creating evaluation tasks. Miners whose deployments are not in a `running` state or have no ready replicas are excluded from the evaluation cycle. This prevents wasting compute on deployments that cannot serve inference requests. |
There was a problem hiding this comment.
Minor doc inconsistency: health check accepts "Active" or "running" state.
Line 174 says miners "not in a running state" are excluded, but kinitro/scheduler/health.py (line 33) accepts both "Active" and "running" as healthy states. Consider updating the docs to reflect both accepted states, or clarify which is canonical.
🤖 Prompt for AI Agents
In `@docs/backend-guide.md` around lines 164 - 174, The docs currently say miners
not in a `running` state are excluded but the scheduler's health check (see
health.py which treats both "Active" and "running" as healthy) accepts both
values; update the backend-guide.md table/paragraph to mention that healthy
deployment states include both "Active" and "running" (or explicitly state which
is canonical) so the documentation matches the behavior in
kinitro/scheduler/health.py.
docs/miner-guide.md
Outdated
| ``` | ||
| ================================================== | ||
| DEPLOYMENT STATUS | ||
| ================================================== | ||
| Name: my-deployment | ||
| State: running | ||
| Replicas: 1/1 | ||
| Image: my-image | ||
| Tag: v1.0 | ||
| Uptime: 2h 30m 15s | ||
| ================================================== | ||
| ``` |
There was a problem hiding this comment.
Add a language specifier to the fenced code block.
The static analysis tool flagged this block (MD040). Since it's sample CLI output, use ```text to satisfy the linter.
Proposed fix
-```
+```text
==================================================
DEPLOYMENT STATUS🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 303-303: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In `@docs/miner-guide.md` around lines 303 - 314, The fenced code block containing
the sample CLI output for "DEPLOYMENT STATUS" should include a language
specifier to satisfy the MD040 linter; update the opening fence from ``` to
```text (and keep the closing fence as ```) so the block is treated as plain
text—locate the block that starts with the
"==================================================" / "DEPLOYMENT STATUS"
sample and add the `text` specifier to the opening backticks.
docs/miner-guide.md
Outdated
| State: running | ||
| Replicas: 1/1 | ||
| Image: my-image | ||
| Tag: v1.0 | ||
| Uptime: 2h 30m 15s | ||
| ================================================== | ||
| ``` | ||
|
|
||
| **Size limits:** HuggingFace repositories larger than 5GB will be rejected. This limit applies to both uploads and verification downloads. | ||
| The scheduler also uses this public metadata API to perform health checks before creating evaluation tasks. Deployments that are not in a `running` state or have no ready replicas will be skipped during evaluation cycles. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check what state value the health check code actually compares against
rg -n "state" --type=py -C3 -g '*/scheduler/health.py'Repository: threetau/kinitro
Length of output: 1102
🏁 Script executed:
#!/bin/bash
# Also check the CLI status command implementation for state handling
rg -n "state" --type=py -C3 -g '*/cli/miner/deploy.py'Repository: threetau/kinitro
Length of output: 1752
🏁 Script executed:
#!/bin/bash
# Look for any references to Basilica SDK or metadata API
rg -n "metadata\|state\|Active\|running" --type=py tests/unit/test_health.py -C2Repository: threetau/kinitro
Length of output: 42
🏁 Script executed:
#!/bin/bash
# Search for health check or deployment status logic
find . -name "*.py" -path "*/scheduler/*" -o -name "*.py" -path "*/health*" | head -20Repository: threetau/kinitro
Length of output: 279
🏁 Script executed:
#!/bin/bash
# Search for Basilica SDK usage and state values
rg -n "basilica\|Basilica\|state.*=\|meta\." --type=py -g '*/cli/miner/deploy.py' -A2 -B2 | head -50Repository: threetau/kinitro
Length of output: 42
🏁 Script executed:
#!/bin/bash
# Check for test fixtures or example responses showing state values
rg -n "state\|Active\|running" --type=py tests/ -g '*test*.py' | grep -i "state\|active\|running" | head -30Repository: threetau/kinitro
Length of output: 42
🏁 Script executed:
#!/bin/bash
# Look at the documentation file to see the exact context
sed -n '308,316p' docs/miner-guide.mdRepository: threetau/kinitro
Length of output: 436
🏁 Script executed:
#!/bin/bash
# Search for any API documentation or comments about state values
rg -n "state" --type=md docs/ -C2Repository: threetau/kinitro
Length of output: 2071
🏁 Script executed:
#!/bin/bash
# Look at the actual health check test file to see what it tests
rg -n "Active\|running\|state" --type=py tests/unit/test_health.py -B2 -A2Repository: threetau/kinitro
Length of output: 42
🏁 Script executed:
#!/bin/bash
# Check the full context of the health.py file to understand the state logic
sed -n '25,50p' kinitro/scheduler/health.pyRepository: threetau/kinitro
Length of output: 822
🏁 Script executed:
#!/bin/bash
# Look for any requirements or setup that shows Basilica SDK version
rg -n "basilica\|Basilica" --type=py -g '*/requirements*' -g '*/setup.py' -g '*/pyproject.toml'Repository: threetau/kinitro
Length of output: 208
🏁 Script executed:
#!/bin/bash
# Find project configuration files
find . -maxdepth 2 -type f \( -name "pyproject.toml" -o -name "requirements*.txt" -o -name "setup.py" \)Repository: threetau/kinitro
Length of output: 76
🏁 Script executed:
#!/bin/bash
# Check pyproject.toml for basilica dependency
cat pyproject.toml | grep -A5 -B5 basilicaRepository: threetau/kinitro
Length of output: 344
🏁 Script executed:
#!/bin/bash
# Look at the complete health check logic including the docstring
sed -n '50,70p' kinitro/scheduler/health.pyRepository: threetau/kinitro
Length of output: 773
🏁 Script executed:
#!/bin/bash
# Look at the complete error message context in health.py
sed -n '32,35p' kinitro/scheduler/health.pyRepository: threetau/kinitro
Length of output: 207
🏁 Script executed:
#!/bin/bash
# Search for any deployment examples or test fixtures that show actual API responses
rg -n "Active\|running" --type=py kinitro/ tests/ -B1 -A1 | head -40Repository: threetau/kinitro
Length of output: 42
🏁 Script executed:
#!/bin/bash
# Check if there are any comments or documentation about Basilica API state values
rg -n "state\|Active" --type=py kinitro/scheduler/health.py -B5 -A5Repository: threetau/kinitro
Length of output: 42
Update docs to reflect that both "Active" and "running" are valid healthy deployment states.
The scheduler health-check code (kinitro/scheduler/health.py line 33) accepts both "Active" and "running" as valid healthy states, but the documentation here only mentions "running". Additionally, the error message states "expected 'Active'" which conflicts with the docstring's claim that only "running" is required.
Update the documentation to clarify that deployments are healthy if their state is either "Active" or "running" and they have at least one ready replica.
🤖 Prompt for AI Agents
In `@docs/miner-guide.md` around lines 308 - 316, Update the docs text to state
that deployments are considered healthy when their state is either "Active" or
"running" and they have at least one ready replica, and adjust the example/error
wording to remove the conflicting "expected 'Active'" phrasing; this should
mirror the scheduler health-check behavior implemented in
kinitro.scheduler.health so the documentation and the scheduler (health-check
logic) consistently report that both "Active" and "running" are valid healthy
states with ready_replicas >= 1.
kinitro/scheduler/health.py
Outdated
| try: | ||
| meta = await asyncio.wait_for( | ||
| client.get_public_deployment_metadata_async(deployment_id), | ||
| timeout=timeout, | ||
| ) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for the async method in the codebase
rg -rn "get_public_deployment_metadata_async" --type pyRepository: threetau/kinitro
Length of output: 644
🏁 Script executed:
#!/bin/bash
# Also search for any references to basilica or client imports
rg -rn "BasilicaClient|get_public_deployment_metadata" --type py | head -50Repository: threetau/kinitro
Length of output: 1811
🏁 Script executed:
#!/bin/bash
# Find dependency specification files
fd -e txt -e toml -e cfg -e yaml | grep -E "(requirements|pyproject|setup|poetry)" | head -20Repository: threetau/kinitro
Length of output: 232
🏁 Script executed:
#!/bin/bash
# Read the health.py file around the specified lines
cat -n kinitro/scheduler/health.py | sed -n '15,35p'Repository: threetau/kinitro
Length of output: 862
🏁 Script executed:
#!/bin/bash
# Check pyproject.toml for basilica-sdk version
cat -n pyproject.toml | grep -A 5 -B 5 -i "basilica"Repository: threetau/kinitro
Length of output: 452
🏁 Script executed:
#!/bin/bash
# Also check deploy.py to see the sync variant usage
cat -n kinitro/cli/miner/deploy.py | grep -A 3 -B 3 "client\.n("Repository: threetau/kinitro
Length of output: 42
🏁 Script executed:
#!/bin/bash
# Read deploy.py to find actual usage
cat -n kinitro/cli/miner/deploy.py | head -80 | tail -50Repository: threetau/kinitro
Length of output: 1753
🏁 Script executed:
#!/bin/bash
# Search for the method call in deploy.py more broadly
rg -n "client\." kinitro/cli/miner/deploy.pyRepository: threetau/kinitro
Length of output: 379
🏁 Script executed:
#!/bin/bash
# Let's search for the actual imports and see what client object is being used
cat -n kinitro/scheduler/health.py | head -20Repository: threetau/kinitro
Length of output: 670
🌐 Web query:
basilica-sdk 0.19.0 get_public_deployment_metadata_async
💡 Result:
basilica-sdk does not appear to have a 0.19.0 release on PyPI (latest shown there is 0.17.0, released Feb 4, 2026) [1]. The 0.19.0 you’re seeing is most likely the Basilica CLI release on GitHub (“Basilica CLI 0.19.0”, Feb 12, 2026) [2].
Because of that, get_public_deployment_metadata_async is not something I can find as a public API in the published basilica-sdk package versions—so if you’re getting an AttributeError, it’s consistent with the method simply not existing in the installed SDK version [1].
If you paste:
- the exact import path/class you’re calling it on, and
pip show basilica-sdk(version) and the traceback,
I can tell you what the closest supported call is in your installed version.
Sources: [1] https://pypi.org/project/basilica-sdk/ , [2] https://github.com/one-covenant/basilica
🏁 Script executed:
#!/bin/bash
# Check deploy.py to see the exact method name used for sync variant
cat -n kinitro/cli/miner/deploy.py | sed -n '535,540p'Repository: threetau/kinitro
Length of output: 392
🏁 Script executed:
#!/bin/bash
# Let's check if there's any basilica-sdk source code or stubs in the repo
find . -type f -name "*.pyi" -o -name "*basilica*" | grep -v "__pycache__" | grep -v ".git"Repository: threetau/kinitro
Length of output: 42
🏁 Script executed:
#!/bin/bash
# Check the test mocks to understand what methods are being tested
cat -n tests/unit/test_health.py | head -50Repository: threetau/kinitro
Length of output: 1952
🏁 Script executed:
#!/bin/bash
# Let's check the exact import and see if there are any type hints or stubs
cat -n kinitro/scheduler/health.py | sed -n '1,30p'Repository: threetau/kinitro
Length of output: 1060
🏁 Script executed:
#!/bin/bash
# Let's see what methods are available - search for "get_public" in the codebase
rg -n "get_public" --type pyRepository: threetau/kinitro
Length of output: 1330
🌐 Web query:
BasilicaClient API methods basilica-sdk documentation
💡 Result:
From the basilica-sdk docs, the BasilicaClient API includes these main methods:
BasilicaClient
BasilicaClient(base_url: str | None = None, api_key: str | None = None)(client constructor) [1]
High-level deploy API
deploy(...) -> Deployment(primary “package + deploy + wait + URL” workflow) [1]
Low-level deployment API
create_deployment(...)get_deployment(name_or_id)delete_deployment(name_or_id)list_deployments()get_deployment_logs(name_or_id, tail=...)[1]
Legacy GPU rental API
list_nodes(...)start_rental(...)get_rental(rental_id)stop_rental(rental_id)[1]
Related: Deployment object methods
Deployment.status()Deployment.logs(tail=None)Deployment.wait_until_ready(timeout=300)Deployment.delete()Deployment.refresh()[2]
Sources: PyPI project description / API reference snippets for basilica-sdk [1], plus the documented Deployment object API [2].
Confirm get_public_deployment_metadata_async availability in basilica-sdk 0.19.0.
The method is called in health.py (line 24) and its sync variant get_public_deployment_metadata is called in deploy.py (line 537), but neither method appears in the official BasilicaClient API documentation. Additionally, basilica-sdk 0.19.0 does not exist on PyPI (latest release is 0.17.0). Verify the correct SDK version and confirm these methods are available; if not, use the documented API methods (get_deployment, etc.) instead.
🤖 Prompt for AI Agents
In `@kinitro/scheduler/health.py` around lines 22 - 26, The code calls
client.get_public_deployment_metadata_async (and elsewhere
get_public_deployment_metadata) which is not in the documented BasilicaClient
API and basilica-sdk 0.19.0 is not on PyPI; verify the installed basilica-sdk
version and replace these calls with the documented methods (e.g.,
client.get_deployment_async or client.get_deployment) or implement a
compatibility wrapper that falls back to get_deployment/get_deployment_async;
update health.py to await the documented async method (or call the sync method
inside a thread if only sync exists) and update deploy.py similarly, and add a
version check or comment noting the required basilica-sdk version.
kinitro/scheduler/health.py
Outdated
| state = getattr(meta, "state", None) | ||
| if state not in ("Active", "running"): | ||
| return False, f"state is '{state}', expected 'Active'" |
There was a problem hiding this comment.
Docstring/code mismatch on accepted states.
Line 33 accepts both "Active" and "running", but the docstring at line 57 says only "running". Also, the unhealthy reason message at line 34 says expected 'Active' but "running" is also accepted.
Suggested fixes
state = getattr(meta, "state", None)
if state not in ("Active", "running"):
- return False, f"state is '{state}', expected 'Active'"
+ return False, f"state is '{state}', expected 'Active' or 'running'"And in the docstring (line 57):
- A deployment is healthy if its state is "running" and it has at least
+ A deployment is healthy if its state is "Active" or "running" and it has at least📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| state = getattr(meta, "state", None) | |
| if state not in ("Active", "running"): | |
| return False, f"state is '{state}', expected 'Active'" | |
| state = getattr(meta, "state", None) | |
| if state not in ("Active", "running"): | |
| return False, f"state is '{state}', expected 'Active' or 'running'" |
🤖 Prompt for AI Agents
In `@kinitro/scheduler/health.py` around lines 32 - 34, The code currently accepts
both "Active" and "running" (state = getattr(meta, "state", None) and if state
not in ("Active", "running")), but the docstring only mentions "running" and the
error message says expected 'Active'; make them consistent by choosing the
canonical accepted state(s) and updating all three places: the accepted tuple in
the state check (keep or remove "Active"), the unhealthy reason string (reflect
the exact accepted values, e.g., "expected 'running'" or "expected one of
('Active','running')"), and the function/class docstring to list the same
accepted state(s); update references to the state variable and meta accordingly
so the code, message, and docstring are aligned.
pyproject.toml
Outdated
| "alembic>=1.14.0", | ||
| # Deployment (Basilica for GPU serverless) | ||
| "basilica-sdk==0.15.0", | ||
| "basilica-sdk==0.19.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
basilica-sdk 0.19.0 PyPI
💡 Result:
basilica-sdk does not have a 0.19.0 release on PyPI. The latest published version on PyPI is 0.17.0, released Feb 4, 2026, and it requires Python >= 3.10. [1]
To install the latest available version:
pip install basilica-sdkOr pin the latest PyPI version explicitly:
pip install basilica-sdk==0.17.0Update basilica-sdk version pin: 0.19.0 does not exist on PyPI.
The specified version 0.19.0 is not published. The latest available version is 0.17.0 (released Feb 4, 2026). Update the pin to basilica-sdk==0.17.0 or the code will fail to install.
🤖 Prompt for AI Agents
In `@pyproject.toml` at line 40, The pyproject dependency line currently pins
"basilica-sdk==0.19.0" which does not exist on PyPI; update that dependency
declaration to "basilica-sdk==0.17.0" (the latest available) so installation
succeeds—locate the line containing the string "basilica-sdk==0.19.0" and
replace the version with 0.17.0.
Shr1ftyy
force-pushed
the
feat/basilica-metadata-api
branch
from
94635ab to
ea963b9
Compare
1 participant
Summary
basilica-sdkfrom 0.15.0 to 0.19.0 (public deployment metadata API)miner push/miner deploykinitro miner status <deployment-id>command for querying deployment health (state, replicas, image, uptime)verification.py, strip verification wiring from worker, config, types, and docsTest plan
uv locksucceeds withbasilica-sdk==0.19.0ruff check .,ruff format --check .,ty check .all passkinitro miner status --helpshows the new commandfrom kinitro.executor.worker import Workerimports cleanly (no verification references)from basilica import BasilicaClientconfirms SDK importkinitro miner pushenrolls metadata after deploykinitro miner status <name>displays deployment metadataSummary by CodeRabbit
New Features
miner statusCLI command to check deployment health and configuration.Documentation
Chores