Skip to content

fix(core): let retries repeat a test after a stale target or a failed model call - #167

Closed
bagrat wants to merge 2 commits into
sedum-dev:mainfrom
bagrat:fix/retry-transient-errors
Closed

bagrat wants to merge 2 commits into
sedum-dev:mainfrom
bagrat:fix/retry-transient-errors

Conversation

@bagrat

@bagrat bagrat commented Oct 21, 2026

Copy link
Copy Markdown
Contributor

What

These step outcomes now fail the step, instead of marking the test could_not_run:

  • a locator result of stale or provider_error;
  • a stale StepExecutionError from the action itself.

As a result, --retries repeats the test. action_uncertain (an action that may have started) and run-wide provider errors behave as before.

Why

--retries only repeats failed tests; could_not_run is final. So one transient hiccup ended a test even with --retries 3:

  • a target re-rendered just before the click;
  • or a single model call timed out.

In one full run of our 133-test suite, 3 tests ended this way (2 stale clicks, 1 provider error), and all passed on a re-run.

stale is always detected before dispatch, so nothing was clicked and repeating the test is safe. A one-off locator provider_error is scoped to the step; run-wide provider failures still stop the run.

Verification

  • Three tests asserted could_not_run for these cases. They now assert failed, and keep their other checks: no re-resolve, no second dispatch, no cache write, no stale replay or evidence frame.
  • pnpm typecheck and pnpm lint are clean, and pnpm test passes (1,444).

… model call

A target that went stale before dispatch, or a single provider failure while
locating it, ended the test as could_not_run, which --retries never repeats.
Fail the step instead; an action that may have started stays uncertain.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U7KCKub793DH4xshQbHCGd
@coldtea-pr-lens

coldtea-pr-lens Bot commented Oct 21, 2026 •

Copy link
Copy Markdown
  • Redraw · drawn at bf1afa1, the branch has moved on

Architecture

Architecture diagram for sedum-dev/sedum at bf1afa1

Play the walkthrough


Data flow

Data flow diagram for sedum-dev/sedum at bf1afa1

Follow each request


Tip

The CLI's render reads .github/pr-lens.yml and applies your renames, exclusions and lane pins at draw time

🪧 More tips
  • Run npx skills add coldteadotai/pr-lens, then tell your coding agent: "Diagram the change you just made with PR Lens and attach it to the pull request."
  • Run npx @coldtea/pr-lens-cli analyze --base origin/main on a branch, then npx @coldtea/pr-lens-cli render .pr-lens/graph.json. Same lenses, your own model key, before the pull request exists
  • Click the link under each diagram to open it on a canvas you can zoom, pan and step through
  • The diagrams are links. Click one to open it on the canvas, then press W or click play to walk through the change
  • Open a diagram on the canvas, then press W or click play to walk through the change one step at a time
  • Set github.comment.collapsed: true in .github/pr-lens.yml to fold the comment behind one View architecture and data flow row. Drawing still runs as before
  • Set github.draw: on-demand in .github/pr-lens.yml and PR Lens stops drawing pull requests on its own. Comment @pr-lens draw on a pull request when you want that one drawn
  • Add .github/workflows/pr-lens.yml with coldteadotai/pr-lens/packages/action@v0 and your model provider's key as its api-key to run PR Lens from your own CI. Any /chat/completions endpoint works
  • After a push, tick Redraw to draw the latest commit
  • Switch GitHub to dark mode and the diagrams follow. The moving dots are this pull request's data in motion

Thanks for using PR Lens! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out on X, Bluesky, Mastodon, Reddit or LinkedIn

codescene-access[bot]

This comment was marked as outdated.

devnacho commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Thanks a lot for this, @bagrat. The diagnosis was right on: a transient stale target ending the test as could_not_run meant --retries never got a chance.

We landed #169 the next day from the same field report (the 133-test suite). It already covers most of this PR:

  • a stale locator result now fails the step (FAILED_LOCATOR_REASONS in sentence-execution.ts);
  • a stale action refusal now fails the step (FAILED_ACTION_CODES);
  • the action-retry and report tests you updated were switched to expect failed there too.

The one part #169 didn't cover is the locator's provider_error from a single failed model call. I've taken that into #171, with your provider-errors test change, the step's error checked too, a readable message for the step, and you as co-author.

Since this PR now conflicts with main and the rest is already there, I'm closing it in favour of #169 + #171. Thanks again!

@devnacho devnacho closed this Oct 23, 2026
devnacho added a commit that referenced this pull request Oct 23, 2026
A locator provider_error that is not run-wide (for example a timeout) now
fails the step instead of marking the test could_not_run, so --retries
can repeat it. Run-wide provider failures still stop the run.

Follow-up to #169, taking the remaining part of #167.


Amp-Thread-ID: https://ampcode.com/threads/T-8894897a-ba72-47ec-b40f-2aacd96b4545

Co-authored-by: Amp <amp@ampcode.com>
Co-authored-by: Bagrat <bagrat@timeline.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants