Skip to content

fix(vitest): report object retry options as a retry count - #391

Merged
gregberge merged 1 commit into
mainfrom
claude/zen-haibt-f90317
Oct 4, 2026
Merged

gregberge merged 1 commit into
mainfrom
claude/zen-haibt-f90317

Conversation

@gregberge

Copy link
Copy Markdown
Member

Description

What

  • buildTestMetadata() reports the configured retries as a number. Since Vitest 4.1 the retry option can be an object ({ count, delay, condition }): the metadata now takes its count, defaulting to 0 like Vitest's own runner (getRetryCount). A number is kept as is, and an unset retry is still left out.
  • CurrentTask.retry in test-context.ts declares the object form, which number | undefined hid.
  • Two tests in metadata.test.ts use real object options: { count: 2, delay: 0 } reports retries: 2, and { delay: 0 } reports 0.

Why

The task keeps the retry option as written, and buildTestMetadata() copied it into the metadata. On Vitest 5.0.2, it("probe", { retry: { count: 1, delay: 0 } }, …) gave retries: {"count":1,"delay":0}, while the metadata schema (packages/util/src/metadata.ts, mirrored in packages/api-client/src/schema.ts) expects number | null. Screenshots and snapshots both read this metadata, so every capture from such a test carried the invalid value.

Vitest sets task.retry to the test's own option or, failing that, the config's test.retry, so an object in the Vitest config would reach every test the same way. Taking only the count also keeps a condition function or RegExp out of the metadata, which crosses the browser/Node RPC boundary.

Type of changes

Bug fix (bug label).

Checklist

  • I have read the CONTRIBUTING doc (there is no CONTRIBUTING doc in this repo)
  • The commits message follows the Conventional Commits' policy
  • Lint and unit tests pass locally
  • I have added tests if needed

Optional checks:

  • My changes requires a change to the documentation
  • I have updated the documentation accordingly

Further comments

Testing

For reviewers

  • packages/core does not validate metadata before upload: readMetadata parses the JSON and updateBuild sends it unchanged. I couldn't check from this repo whether the API rejects an object retries. If it validates the request body, the whole updateBuild request would fail, not just one screenshot.
  • The unit tests run only on the workspace's Vitest 5. The Vitest 4 compat jobs run the e2e project, so the new tests never run on 4.0, which has no object form.

🤖 Generated with Claude Code

Since Vitest 4.1, a test's `retry` option can be an object
(`{ count, delay, condition }`) and the task keeps it as is.
`buildTestMetadata()` copied `task.retry` into the metadata, so a test
with `{ retry: { count: 1, delay: 0 } }` got
`retries: { count: 1, delay: 0 }` where the Argos metadata schema
expects a number. A `test.retry` object in the Vitest config would reach
every test the same way.

The metadata now takes the object's `count`, defaulting to 0 like
Vitest's own runner, so a `condition` function or RegExp never ends up
in it. A number is kept as is and an unset retry is still left out.
`CurrentTask.retry` now declares the object form.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@gregberge gregberge added the bug Something isn't working label Oct 4, 2026
@vercel

vercel Bot commented Oct 4, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
argos-js-sdk-reference Ready Ready Preview Oct 4, 2026 8:01am UTC

Request Review

@gregberge
gregberge merged commit 921c141 into main Oct 4, 2026
79 checks passed
@gregberge
gregberge deleted the claude/zen-haibt-f90317 branch October 4, 2026 08:25

This branch was successfully deployed

1 active deployment
Preview — 9a7bff69 Deployed Oct 4, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant