• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

run-llama / llama-agents / 39347620111
85%

Build:
DEFAULT BRANCH: main
Ran 20 Oct 2026 12:26AM UTC
Jobs 0
Files 0
Run time –
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

pending completion
  cancel
39347620111

push

github

web-flow
fix(workflows): fail the run when a retry policy raises (#807)

`packages/llama-index-workflows/src/workflows/runtime/control_loop/runner.py:321`
asks the retry policy for a delay inside `_stamp_retry_decisions`. A
policy that raises escapes the worker task, and `runner.py:590` logs
`Worker task failed unexpectedly` and drops it. The step stays in
progress, so the run waits for its timeout.

Before:

```
$ uv run pytest packages/llama-index-workflows/tests/test_retry_policy_raise.py -p no:cacheprovider
2 failed, 4 warnings in 7.65s
```

After:

```
$ uv run pytest packages/llama-index-workflows/tests/test_retry_policy_raise.py -p no:cacheprovider
2 passed, 6 warnings in 2.71s
```

`_stamp_retry_decisions` stamps the verdict at tick creation, ahead of
the journal write. `retry_steps.md:243` says "When a policy gives up,
the exception propagates and fails the workflow, unless a `@catch_error`
handler is declared." `RetryDecision.delay` documents `None to stop
retrying`, so a policy that raises cannot decide and records a stop.

### Verification

```
$ uv run dev -p workflows
1 package passed, 1073 tests
```

Baseline on `5c55ee3` is `1 package passed, 1071 tests`, so the delta is
the 2 new tests. I reverted `runner.py`, kept the tests, and got `2
failed, 4 warnings in 7.71s`. `pre-commit run --files` reports ruff
format, ruff check, ty, basedpyright and codespell clean at that commit.

Not run: the docker-marked integration suite, and the 7 `llamactl` apply
failures that fail the same way on `5c55ee3`.

Fixes #803

@adrianlyjak I surface the policy's error and chain the step's exception
as its cause. #803 proposed the policy's error as `__cause__` instead,
and the journal keeps type and message only
(`events.py:_serialize_exception`), so a chained policy error would
leave `WorkflowFailedEvent.exception` naming the step error and reading
as ordinary exhaustion. Keep it this way round?

---------

Signed-off-by: Christopher Krah <48338417+chrikrah@users.n... (continued)
Source Files on build 39347620111
Detailed source file information is not available for this build.
  • Back to Repo
  • Github Actions Build #39347620111
  • 656b3fc5 on github
  • Prev Build on main (#39347029776)
  • Next Build on main (#39534293155)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc