fix(meta): never reap the single SQLite meta store connection

[yuhao-su]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Mitigation for the CI silent meta hang #24991 (full root-cause analysis: #24991 (comment)).

The file-backed SQLite meta store previously kept the config default idle_timeout_sec = 30 (only the in-memory branch overrode it with MAX_DURATION), which keeps sqlx's background pool-reaper task alive. sqlx 0.8.2 has a num_idle accounting race — release() publishes the connection and releases the semaphore permit before incrementing num_idle, so a concurrent pop_idle can decrement first — that transiently underflows the counter to ~2^64. If the reaper's 30s tick happens to sample the underflow as its sweep-loop bound (for _ in 0..pool.num_idle()), it spins try_acquire inside a single poll without ever yielding (the loop body has no await; try_acquire consumes no coop budget). During the spin, one add_permits hands the only permit to a queued waiter whose wakeup lands in the spinning worker's LIFO slot — not stealable on tokio 1.49 (tokio-rs/tokio#4941) — so the waiter never runs, the permit stays assigned forever, and the single-connection pool is permanently wedged. Every meta DB access then queues forever (acquire_timeout is effectively infinite per #18966), presenting as the silent hang: commit_epoch stuck ~150s+, DDL frozen, heartbeat timeouts.

Upstream status: the same bug is independently reported in transact-rs/sqlx#3645 ("100% CPU in spawn_maintenance_tasks") with a fix pending in transact-rs/sqlx#4289; it is unmerged and no released sqlx version contains it.

This PR removes the ignition site by never expiring the single SQLite connection: move .idle_timeout(MAX_DURATION).max_lifetime(MAX_DURATION) into sqlite_common() so both the in-memory and file-backed branches get them (the in-memory branch already did this for its own reason — releasing the connection clears the in-memory database). With max_connections = 1 against a local SQLite file, idle/lifetime reaping serves no purpose anyway.

A follow-up will fix the underlying num_idle race in the pinned madsim sqlx fork (mirroring transact-rs/sqlx#4289).

Note: file-backed SQLite is also the meta store for standalone/single-node deployments, so this hazard is not CI-only; this change is a low-risk cherry-pick candidate for release branches.

• Related: Flaky e2e: system hung causing timeout #24991 (removes the trigger for the hang; leaving closure until CI soaks)

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• I have checked the Release Timeline and Currently Supported Versions to determine which release branches I need to cherry-pick this PR into.

Documentation

• My PR needs documentation updates.

Release note

[yuhao-su]

• fix(meta): never reap the single SQLite meta store connection #26125 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[yuhao-su]

Closing in favor of fixing the root cause directly in the pinned madsim sqlx fork (cherry-picking transact-rs/sqlx#4289's num_idle underflow fix), which covers all backends rather than only removing the SQLite reaper trigger.