From 5d57c287fb5ce2f5da82d75ed7837758701d5b1e Mon Sep 17 00:00:00 2001 From: wxiaoguang Date: Mon, 25 Nov 2024 14:10:11 +0800 Subject: [PATCH] Fix sqlite3 test (#32622) --- tests/integration/api_issue_test.go | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/tests/integration/api_issue_test.go b/tests/integration/api_issue_test.go index 5b9f16ef96..9f75478ebf 100644 --- a/tests/integration/api_issue_test.go +++ b/tests/integration/api_issue_test.go @@ -144,6 +144,18 @@ func TestAPICreateIssue(t *testing.T) { func TestAPICreateIssueParallel(t *testing.T) { defer tests.PrepareTestEnv(t)() + + // FIXME: There seems to be a bug in github.com/mattn/go-sqlite3 with sqlite_unlock_notify, when doing concurrent writes to the same database, + // some requests may get stuck in "go-sqlite3.(*SQLiteRows).Next", "go-sqlite3.(*SQLiteStmt).exec" and "go-sqlite3.unlock_notify_wait", + // because the "unlock_notify_wait" never returns and the internal lock never gets releases. + // + // The trigger is: a previous test created issues and made the real issue indexer queue start processing, then this test does concurrent writing. + // Adding this "Sleep" makes go-sqlite3 "finish" some internal operations before concurrent writes and then won't get stuck. + // To reproduce: make a new test run these 2 tests enough times: + // > func TestBug() { for i := 0; i < 100; i++ { testAPICreateIssue(t); testAPICreateIssueParallel(t) } } + // Usually the test gets stuck in fewer than 10 iterations without this "sleep". + time.Sleep(time.Second) + const body, title = "apiTestBody", "apiTestTitle" repoBefore := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: 1})