chore: regenerate poetry.lock for the jsonschema dev dependency

[ling-senpeng13]

Fixes #456.

What

jsonschema = ">=4.23" was added to [tool.poetry.group.dev.dependencies] without regenerating the lock, so poetry's stored content-hash stopped matching pyproject.toml. Every poetry install since then fails its consistency check:

pyproject.toml changed significantly since poetry.lock was last generated.
Run `poetry lock` to fix the lock file.

That is what broke the PyPI publish for 2.0.0-rc3: the GitHub release and its e2e bundle were created, but no wheel was ever uploaded. So pip install conductor-python==2.0.0-rc3 fails, and the released conductor-ai-e2e-python-2.0.0-rc3 bundle — which pins that exact version — cannot install. Full write-up in #456.

This is a bookkeeping fix, not a dependency change

jsonschema 4.26.0 was already in the lock and already satisfies >=4.23. It was just recorded as an optional, extras-gated transitive dependency rather than a dev-group one. So the diff only re-tags entries and refreshes the hash:

-optional = true
+optional = false
-groups = ["main"]
+groups = ["main", "dev"]
-markers = "extra == \"openai-agents\" or …"
+markers = {main = "extra == \"openai-agents\" or …"}
...
-content-hash = "f3c1edfc…"
+content-hash = "c9fd605d…"

No package version changed. Verified by diffing every version = line in the lock — zero hits. One file, 19 insertions / 19 deletions.

Exactly five entries change — jsonschema and its transitive closure: attrs, jsonschema, jsonschema-specifications, referencing, rpds-py — plus [metadata] content-hash. Nothing else in the lock is touched.

Verification

Run with poetry 2.4.1, matching the lock's lock-version 2.1:

	poetry check --lock
before	exit 1 — pyproject.toml changed significantly since poetry.lock was last generated
after	exit 0

Note for whoever cuts the next release

Re-running 2.0.0-rc3's Continuous Delivery will not fix that release — it rebuilds the 2.0.0-rc3 tag, which still has the stale lock committed in it. A new release (2.0.0-rc4) is required, and it's worth confirming conductor-python 2.0.0rc4 actually appears on PyPI afterwards rather than trusting the release page.

#456 also proposes hardening so this can't recur silently — most usefully, poetry check --lock in PR CI (it reproduces this exact failure in one step) and gating the e2e-bundle upload on the package existing on PyPI.

CI note

integration-test (test-all) failed on the first run with:

tests/integration/test_workflow_client_intg.py::TestOrkesWorkflowClientIntg::test_all
Exception: workflow expected to be COMPLETED, but received RUNNING, workflow_id: de37587d-…

That is a workflow not reaching a terminal state inside the poll window against the shared server — unrelated to this change. The five entries touched here (jsonschema + attrs/referencing/rpds-py/jsonschema-specifications) are JSON-schema validation libraries, at unchanged versions; none participates in workflow execution, polling or worker dispatch. unit-test and the other three integration shards passed.

Worth noting pyproject.toml already carries markers acknowledging this area is timing-sensitive — slow_test_all: long-running aggregate workflow-client test_all (~83s) and server_timeout_unreliable: … excluded from CI. Happy to re-run that shard to confirm.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.