test: fix flaky TestResourceIndex and reduce its runtime (#37847)

The modernc SQLite driver (default since
https://github.com/go-gitea/gitea/pull/37562) returns `SQLITE_BUSY` once
the busy timeout is reached, unlike mattn which waited indefinitely.
`TestResourceIndex` fires many concurrent `NewIssue` writers, but SQLite
serializes all writers, so they queue on a single `BEGIN IMMEDIATE`
write lock. Under `-race` (modernc is much slower) the goroutines at the
back of the queue exceeded the hardcoded 5s test timeout, producing
`database is locked (5) (SQLITE_BUSY)`.

Changes:
- Reduce the concurrent inserts from 25 to 10. Since SQLite serializes
writers, the extra goroutines only deepen the busy-lock queue without
adding coverage. 10 still exercises concurrent index allocation while
cutting the test's `-race` runtime ~3x (2.76s to 0.86s locally).
- Share the busy-timeout constant: export `DefaultSQLiteBusyTimeout`
(20s, the production default) and reference it from the test engine
instead of the hardcoded `5000`.

Observed flake:
https://github.com/go-gitea/gitea/actions/runs/26394082930/job/77690496092

---
This PR was written with the help of Claude Opus 4.7

---------

Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com>
This commit is contained in:
silverwind
2026-05-26 05:06:54 +00:00
committed by GitHub
co-authored by Claude
parent 5badd1bdee
commit 3223d919b0
4 changed files with 6 additions and 6 deletions
+1 -1
View File
@@ -7,7 +7,7 @@
- Run single playwright e2e test files with `GITEA_TEST_E2E_FLAGS='<filepath>' make test-e2e`
- Add the current year into the copyright header of new `.go` files
- Ensure no trailing whitespace in edited files
- Use Conventional Commits format for commit messages and PR titles (for example `type(scope): subject`; place `!` immediately before the colon when the change is breaking)
- Use Conventional Commits for commit messages and PR titles, e.g. `type(scope): subject`; `!` before the colon if breaking. Use `test` type for test-only changes.
- Never force-push, amend, or squash unless asked. Use new commits and normal push for pull request updates
- Preserve existing code comments, do not remove or rewrite comments that are still relevant
- Keep comments short, prefer same-line, explain why, never narrate code