The server package moved from llama-index-workflows to llama-agents-server,
but the update-index-html CLI command and GitHub Actions workflow still
referenced the old path. Update both to point to the new location at
packages/llama-agents-server/src/llama_agents/server/static/index.html.
https://claude.ai/code/session_01QTCs9m11U3ubvmXmKAfg6A
Co-authored-by: Claude <noreply@anthropic.com>
* Add xfailing test for concurrent step cancellation regression in 2.14.0
This test exposes a regression introduced in 2.14.0:
- In 2.13.1: A single asyncio.sleep(0) yield after stop_step returns is
sufficient for cancellation to propagate, blocking other_step's write.
- In 2.14.0: The yield is not enough - other_step's write still goes through.
Test sequence:
1. stop_step returns StopEvent
2. Single yield point (asyncio.sleep(0))
3. other_step writes to stream
In 2.13.1: write is blocked (PASS)
In 2.14.0: write goes through (FAIL)
The architectural change from asyncio.Queue to tick_buffer + wait_for_next_task
in commit 45e7614 ("Remove asyncio queue from control_loop #315") changed the
timing characteristics, requiring longer delays for cancellation to take effect.
In 2.13.1, workers immediately put ticks in the queue via queue_tick(), and
the continuous _pull() task meant quick processing. In 2.14.0, workers return
results collected by wait_for_next_task, adding overhead that delays cancellation.
Related: https://llama-index.slack.com/archives/C0A3TFERFHV/p1770391664693399https://claude.ai/code/session_01VWUvDsJ88uaVn4jT68Ny8X
* Fix concurrent step cancellation regression in 2.14.0
When a worker returns a StopEvent, immediately cancel other running
workers before adding the tick to the buffer. This restores the 2.13.1
behavior where a single asyncio.sleep(0) yield after stop_step returns
is sufficient for cancellation to propagate.
The regression was introduced in commit 45e7614 ("Remove asyncio queue
from control_loop #315") which changed the architecture from asyncio.Queue
to tick_buffer + wait_for_next_task. The new architecture had more overhead,
causing cancellation to take longer.
The fix checks if the completed worker's result contains a StopEvent, and
if so, calls cleanup_tasks() immediately to cancel other workers before
they can write to the event stream.
Also removes internal implementation references from comments.
Fixes: https://llama-index.slack.com/archives/C0A3TFERFHV/p1770391664693399https://claude.ai/code/session_01VWUvDsJ88uaVn4jT68Ny8X
* Add patch changeset for concurrent step cancellation fix
* fix lint
* Improve StopEvent cancellation speed for sibling steps
---------
Co-authored-by: Claude <noreply@anthropic.com>
* Fix openapi generation script to use correct module path
The hatch script `server:openapi` was invoking `python -m workflows.server.server`,
but `workflows.server` is just a re-export shim with no `server.py` submodule.
The actual module with the `__main__` block lives at `llama_agents.server.server`.
* Move OpenAPI generation from workflows package to server package
The hatch openapi script and CI workflow were configured in the
llama-index-workflows package, which required a special hatch environment
with the `server` extra to access the server module. Since the actual
server code lives in llama-agents-server, move everything there where
all dependencies are already available directly.
- Add hatch config and openapi script to llama-agents-server pyproject.toml
- Remove hatch config and hatch dev dep from llama-index-workflows pyproject.toml
- Update publish_openapi.yml to run from packages/llama-agents-server
Add documentation explaining that changes made during Agent Builder sessions
don't automatically update existing deployments. Users must explicitly push
changes to GitHub and redeploy to update their production workflow. This
enables safe experimentation without affecting stable deployments.
https://claude.ai/code/session_01Rok9AU8XDhhgH1x3FhbhGg
Co-authored-by: Claude <noreply@anthropic.com>
* chore: CI/testing improvements for parallel test execution
- Add workflows-dev pytest command with parallel test runner
- Add pytest-xdist for parallel test execution (-nauto)
- Add timeouts to prevent test hangs (--timeout=10/60/120)
- Use module-scoped async fixtures for faster tests
- Remove mypy in favor of basedpyright/ty type checking
- Add test-docker CI job for integration tests with testcontainers
- Exclude integration tests from Python 3.9/3.14 in CI matrix
* refact: introduce runtime plugin architecture and context separation
- Add Runtime abstract base class with BasicRuntime as default implementation
- Split context into external, internal, and pre-context modules
- Replace workflow_registry with workflow_tracker for workflow lifecycle management
- Remove broker.py in favor of runtime-managed execution
- Add plugins package with get_current_runtime() for context-aware runtime access
- Update handler and workflow to use new runtime interfaces
Change the debugger asset update workflow to use a fixed filename
(.changeset/update-debugger-assets.md) instead of a timestamp-based
one. This ensures multiple updates accumulate into a single changelog
entry with the latest contents, rather than creating separate entries
for each update.
https://claude.ai/code/session_018SR5swLkGS4mVgY8RUR9iP
Co-authored-by: Claude <noreply@anthropic.com>
* prep packages
* wrong coverage detection I think
* add ts deps?
* extend path for namespaces
* the big move, import issues though
* llama_index.workflows
* llama_agents
* alias may be working
* add type checker ignores for workflows secondary namespace, update ty, and add re-exports
* Add descriptions to new client and server packages
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Rather, commit the outputs
* keep the py files separate
* ignore examples deps
* Create afraid-books-own.md
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* docs: add guide for handling blocking code in workflows
Workflows run on asyncio, so blocking calls in steps stall the entire
event loop. This new page documents best practices:
- Offload blocking I/O to threads with asyncio.to_thread
- Offload CPU-intensive work to a small dedicated thread/process pool
using loop.run_in_executor
https://claude.ai/code/session_018DdW3KPH2nt1FbWECt1uKF
* reframe to async
* docs: link to async Python overview from async workflows guide
---------
Co-authored-by: Claude <noreply@anthropic.com>
* feat: Add resource and resource config validation to workflow validate()
Adds optional resource validation to validate():
- validate_resource_configs (default True): Validates config files exist
and match their Pydantic schemas
- validate_resources (default False): Resolves resource factories, also
catches circular dependencies via ResourceManager
Key implementation:
- _validate_resource_configs(): Stack-based traversal of all resources
and their dependencies, validates _ResourceConfig instances
- _validate_resources(): Resolves resources via ResourceManager.get()
- validate() now runs even with disable_validation=True when called
explicitly
- Python 3.9 compat: restore event loop after asyncio.run()
* Create smooth-donkeys-run.md
* Update test_resources.py
Kill off a silly extra test
---------
Co-authored-by: Claude <noreply@anthropic.com>
Adrian Lyjak