fix(db): restore SQLx statement caching to prevent pipeline crashes

[jjleng]

No description provided.

[jjleng]

@claude

[claude]

Claude finished @jjleng's task in 1m 35s —— View job

---

Code Review

• Gather context and read changed files
• Analyze the PR diff
• Provide review feedback

---

Summary

This PR reverses the previous decision to disable SQLx's prepared-statement cache (statement_cache_capacity(0)). The new stance is: use statement caching (extended query protocol) and require the connection pooler to be in Session Mode rather than Transaction Mode. The db.rs module comment is updated accordingly.

There are also unrelated UI removals in studio/ (the "Copy Agent ID" menu item).

---

Issues

1. Dangling/broken comment in voice/server/src/main.rs:47-51

The removal of statement_cache_capacity(0) left the surrounding comment half-deleted, producing a sentence fragment:

// Connect to the same Postgres DB as the Python backend.
// protocol for every query, which is required by Supabase/PgBouncer in
// transaction mode. Without this, parallel sqlx queries (tokio::join!) can
// hit a connection with a stale prepared-statement handle, causing
// "unnamed prepared statement does not exist" errors.

Line 48 begins with // protocol for every query — the leading sentence that explained what forced the simple-query protocol (the statement_cache_capacity(0) call) was removed, leaving a dangling clause. The remaining lines now describe the old problem in a misleading context (they say "without this" but there is no "this" anymore).

The comment should be rewritten to reflect the current approach. Fix this →

2. No-op let connect_opts = connect_opts; in integrations/src/python.rs

Two spots (lines 111 and 305) now have:

let connect_opts = connect_opts;

These are pure no-ops left over from replacing the statement_cache_capacity(0) call. They add visual noise and will likely trigger a Clippy warning (clippy::let_unit_value or clippy::redundant_let_else depending on version). They should be removed entirely. Fix this →

3. Stale comment in integrations/src/python.rs:297

The get_or_create_runtime_and_pool function still has:

// Create the pool on the new runtime with PgBouncer-safe settings

"PgBouncer-safe" was the justification for statement_cache_capacity(0). Now that the setting is gone, the comment is misleading — the pool no longer uses any special PgBouncer settings. Fix this →

---

Nits

• The studio/ change (removing "Copy Agent ID") appears unrelated to the DB fix. Fine to bundle here, but consider whether a separate commit message / PR would be cleaner for the changelog.

---

Overall

The core logic change (re-enabling prepared statements, requiring session-mode pooler) is reasonable and the db.rs doc-comment is updated correctly. The main concerns are the broken comment in main.rs and the leftover no-op lines in python.rs — both are low-risk but will confuse future readers.