Repository navigation
fix(vitest): report object retry options as a retry count - #391
Merged
Merged
Conversation
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>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
What
buildTestMetadata()reports the configured retries as a number. Since Vitest 4.1 theretryoption can be an object ({ count, delay, condition }): the metadata now takes itscount, defaulting to 0 like Vitest's own runner (getRetryCount). A number is kept as is, and an unset retry is still left out.CurrentTask.retryintest-context.tsdeclares the object form, whichnumber | undefinedhid.metadata.test.tsuse real object options:{ count: 2, delay: 0 }reportsretries: 2, and{ delay: 0 }reports0.Why
The task keeps the
retryoption as written, andbuildTestMetadata()copied it into the metadata. On Vitest 5.0.2,it("probe", { retry: { count: 1, delay: 0 } }, …)gaveretries: {"count":1,"delay":0}, while the metadata schema (packages/util/src/metadata.ts, mirrored inpackages/api-client/src/schema.ts) expectsnumber | null. Screenshots and snapshots both read this metadata, so every capture from such a test carried the invalid value.Vitest sets
task.retryto the test's own option or, failing that, the config'stest.retry, so an object in the Vitest config would reach every test the same way. Taking only the count also keeps aconditionfunction or RegExp out of the metadata, which crosses the browser/Node RPC boundary.Type of changes
Bug fix (
buglabel).Checklist
Optional checks:
Further comments
Testing
vitest run --project unitinpackages/vitest: 50 tests pass. The two new tests fail on the previous code, which returned{ count: 2, delay: 0 }and{ delay: 0 }.tscandeslint .inpackages/vitest, and Prettier on the changed files, pass.metadata.tsandtest-context.ts. It merges cleanly with currentmain, and the merged tree passes the unit tests (51 with fix(vitest): make argosScreenshot and auto-naming work on Vitest 4.0 #390's),tscandeslint.For reviewers
packages/coredoes not validate metadata before upload:readMetadataparses the JSON andupdateBuildsends it unchanged. I couldn't check from this repo whether the API rejects an objectretries. If it validates the request body, the wholeupdateBuildrequest would fail, not just one screenshot.🤖 Generated with Claude Code