fix(api): give the migration tests a timeout that matches their work - #582
Conversation
They drive a real libsql file database through the whole migration catalog — the second one twice — which is legitimately slower than vitest's 5s default. CI measured 3.0s and 7.4s, so the slower one times out intermittently and blocked #581 until a rerun. Scoped to the two tests rather than a global testTimeout bump, which would mask genuinely slow unit tests elsewhere. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 12 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…585) ## Context I enabled **Allow GitHub Actions to create and approve pull requests** at the org and repo level, which unblocked `sync-develop` — it had been failing with `GitHub Actions is not permitted to create or approve pull requests` since forever. Re-running it against the v0.17.0 build now succeeds. But it immediately produced #584, which **cannot merge**. ## The problem `sync-develop` opened a `develop ← main` PR. That shape deadlocks: `develop` requires the head branch to be up to date, and `main` falls behind `develop` the moment anything lands after the release — #582 and #583 did exactly that. #584 has been sitting at `BEHIND` since it was created. I hit the same wall by hand earlier tonight with #577. Even if it could merge, the squash auto-merge would replay the content as a fresh commit and **not** establish ancestry, which is the entire point of a back-merge. That is what went wrong in #578 and #579. ## The fix Push a branch descended from `develop` with `main` merged into it, then open that against `develop`. Same thing that finally worked manually in #581. - Named `chore/backmerge-main-<tag>`, which matches the exclusion added in #580 so `automerge.yml` leaves it alone. - The job arms auto-merge itself with `--merge`, so it lands as a merge commit. - Exits early when `main` is already an ancestor, or when the branch already exists, so re-runs are safe. ## Follow-up #584 should be closed — this replaces it. The next release will exercise this path for real. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
🎉 This PR is included in version 0.18.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
1 participant
Problem
tests/runMigrations.test.ts > records migrations that already exist in the schematimes out intermittently and blocks unrelated PRs. It blocked #581 until I reran the job, which then passed — a flake, not a break.Why it is slow
Not a bug. Each test creates a real libsql file database in
/tmpand drives the entireMIGRATIONScatalog through it. The failing one callsapplyMigrationstwice. CI measured:vitest's default is 5000 ms and there is no
testTimeoutconfigured anywhere in the repo. The suite has been living one runner hiccup away from red.Fix
An explicit 30s budget on those two tests, with a comment saying why.
Scoped deliberately: a global
testTimeoutbump would hide genuinely slow unit tests elsewhere. These two are the only ones doing real database I/O, so they are the only ones that should carry a longer budget.Verified locally:
pnpm --filter @dripnex/api test→ 59/59 pass.🤖 Generated with Claude Code