Repository navigation
test(runner): a conformance kit every [runner] must pass, run against LocalRunner - #269
Merged
Merged
Conversation
earakely-scale
approved these changes
Oct 21, 2026
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
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
The stores have shared kits in
tst/store/that every backend must pass; runners had none, so the contracttask run,task run-batch,eval runand the explorer rely on lived only inLocalRunner's own tests and the CLI tests. This addstst/runner/conformance.py, in the same shape as the store kits (plain functions plusCASES), and runs it againstLocalRunner.Each case gets a runner that was never started (the CLI never calls
start()) and is stopped afterwards. The cases store real tasks withTask.putand read the run index and the task instances, so a remote runner passes only if its worker shares the caller's stores and has the kit'sStepregistered. A Temporal runner plugin can run the same cases against a test server and an in-process worker.a_run_completes_and_is_recorded_under_its_handleCOMPLETED; the record carries the handle'srun_id,instance_idand task; the stored instance carriesworkflow_id, the submitted metadata and what the step wrotea_run_whose_step_fails_fails_with_its_errorFAILEDwith the step's error, in the status and the indexa_cancelled_run_ends_canceledcancel()of a started run returns True and the run endsCANCELEDa_run_given_an_instance_continues_it_from_start_stepsubmit(instance_id=...)keeps the instance, starts frommetadata["start_step"]without rerunning earlier steps, and carries their stored contexta_run_it_does_not_have_or_that_ended_cannot_be_cancelledcancel()is False for an ended or unknown run;status()is None for an unknown oneLeft out to keep this small:
KEEP_KEY(observing a teardown neutrally needs a fake sandbox provider configured in the worker) and a started runner, the explorer's mode.Validation
LocalRunner, 15 times in a row under-n 4.LocalRunnerfails at least one case: a resume that restarts from step 0, one that ignores the stored instance, one that mints a new instance, noworkflow_id, dropped metadata, a cancel recorded asFAILED,cancel()returning True for an ended run, and a failed run recorded asCOMPLETED.test_mcp_cli_builder.pyalso fail on main locally (the generated script runs under a systempython3withoutclick).

Confidence Score: 5/5
The PR appears safe to merge, with no outstanding findings.Summary
Adds five shared runner checks and runs them against
LocalRunner.Reviews (4) · Last reviewed commit: "test(runner): validate saved run identit..." · Reviewed by Greptile