From d3f681f614b0a254e208a684dc7ada7785e0e14c Mon Sep 17 00:00:00 2001 From: wxiaoguang Date: Sat, 23 Nov 2024 15:11:28 +0800 Subject: [PATCH] fix --- 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..304c614fcd 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 go-sqlite, 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})