TestSqlCatalog/TestConcurrentTableViewCollisionReturnsCatalogSentinel (added in #1489) failed twice in a row on ubuntu-latest go1.26.1 in PR #1785, which doesn't touch catalog/sql:
Failure in both cases:
Error: Target error should be in err chain:
expected: "table already exists"
in chain: "failed to create view: database is locked (5) (SQLITE_BUSY)"
The test races a table create against a view create and expects the loser to get the table already exists catalog sentinel, but on ubuntu runners the losing writer sometimes hits SQLite's SQLITE_BUSY instead — the lock contention surfaces before the uniqueness check does. It passes consistently on macOS locally (10/10 with -count=10) and on the macOS CI jobs.
Possible fixes: set _busy_timeout/_txlock=immediate in the test DSN so the losing writer waits for the lock instead of erroring, or have the test also accept a retry-on-busy path. Happy to send a PR if maintainers have a preference.
Made with Cursor
TestSqlCatalog/TestConcurrentTableViewCollisionReturnsCatalogSentinel(added in #1489) failed twice in a row onubuntu-latest go1.26.1in PR #1785, which doesn't touchcatalog/sql:Failure in both cases:
The test races a table create against a view create and expects the loser to get the
table already existscatalog sentinel, but on ubuntu runners the losing writer sometimes hits SQLite'sSQLITE_BUSYinstead — the lock contention surfaces before the uniqueness check does. It passes consistently on macOS locally (10/10 with-count=10) and on the macOS CI jobs.Possible fixes: set
_busy_timeout/_txlock=immediatein the test DSN so the losing writer waits for the lock instead of erroring, or have the test also accept a retry-on-busy path. Happy to send a PR if maintainers have a preference.Made with Cursor