fix(client): reject nonpositive wait controls before submitting a task

[basil-k-aji-dev]

Closes #83.

Problem

ArtemisClient.run() awaits submit() and only then calls wait_for_task(), which is where timeout and poll_interval are validated. A caller that passes a nonpositive value therefore gets a ValueError and no task handle, while a real host may already have admitted and started the submitted task. run_task() delegates to run() and inherited the same behaviour.

wait_for_task() called directly already rejects these values without touching the transport, so the contract was inconsistent between the two entry points.

Reproduced with the injected transport interface from the issue (no server, device or credentials needed) — on main:

ValueError timeout must be greater than zero
[('POST', '/api/run')]

Change

packages/artemis-client/src/artemis_client/client.py

• New _resolve_wait_controls(timeout, poll_interval) holding the two checks that wait_for_task() already performed, and returning the resolved poll interval.
• wait_for_task() calls it — same behaviour, same messages.
• run() calls it before submit(), and passes the resolved interval on to wait_for_task() so the value is resolved once rather than twice.

No public signature changes. Valid calls are unaffected.

After the change, all four invalid combinations reach the transport zero times:

{'timeout': 0}          -> ValueError(timeout must be greater than zero)       ; transport calls = []
{'timeout': -1}         -> ValueError(timeout must be greater than zero)       ; transport calls = []
{'poll_interval': 0}    -> ValueError(poll_interval must be greater than zero) ; transport calls = []
{'poll_interval': -0.5} -> ValueError(poll_interval must be greater than zero) ; transport calls = []

Tests

packages/artemis-client/tests/test_client.py

• test_run_rejects_nonpositive_wait_controls_without_submitting — four subtests (zero/negative for each control) asserting both the ValueError message and transport.calls == [].
• test_run_task_rejects_nonpositive_wait_controls_without_submitting — the same guarantee through the run_task() entry point named in the issue.
• test_run_still_submits_and_completes_with_valid_wait_controls — a submit-and-complete run still issues exactly POST /api/run then GET /api/sessions/{id}, so the new early return cannot silently swallow valid calls.

The six invalid-input subtests fail on main with AssertionError: Unexpected request: POST /api/run and pass here.

Verification

Command	Result
uv run pytest -q packages/artemis-client/tests	23 passed, 6 subtests passed
uv run pytest -q (full deterministic suite)	no change in outcomes vs. main on this host
uv run ruff format --check packages/artemis-client	10 files already formatted
uv run ruff check packages/artemis-client	All checks passed

make typecheck could not be run in my environment — the pyright wheel fetches a Node runtime on first use and my sandbox blocks the download. artemis_client is inside pyright-core.json, so please let CI confirm that step. The change adds one method with fully annotated parameters and a tuple[float, float] return, and removes no annotations.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Chris0Jeky]

Thanks for picking up #83! I independently checked fb3c502 on Windows with Python 3.12: all eight zero/negative cases through run() and run_task() made zero transport requests; the same cases each submitted on the base before raising. Direct-wait rejection and valid submit-and-complete controls also passed, including integer, fractional and default polling values. The client tests, scoped Ruff checks and protected-core types passed. This used fake transport, not a live host; I didn't rerun the full upstream suite, and CI still awaits maintainer approval. No blocking issue found in this check.

[basil-k-aji-dev]

@Chris0Jeky thank you, and sorry for the slow reply. Independent verification on a platform I do not have is worth more than another run of mine on Linux, and you checked the thing that actually matters: zero transport requests on the rejecting path, and a submit on the base before the raise. That is the difference #83 describes, confirmed from outside my own assumptions.

Your caveats are the right ones to state. Fake transport rather than a live host means this says the client stops before the call, not that a real Artemis host behaves as expected once it does call; and the full upstream suite is still CI's to run. I have not changed anything since fb3c502, so your check still describes the tip.

Nothing needed from me unless a maintainer wants something changed.