fix(plugins): respect Settings > Query timeout in HTTP transports (#1267)

[datlechin]

Fixes #1267.

Root cause

Six HTTP-transport plugins hardcoded URLSessionConfiguration.timeoutIntervalForRequest = 30 (60 for BigQuery) at session creation. The user's Settings > Query timeout IS applied (DatabaseManager+Sessions.swift:104 calls driver.applyQueryTimeout(seconds) after connect, which sends SET max_execution_time = N for ClickHouse), but the URLSession cancels the underlying HTTP request before the server can respond. The user sees NSURLErrorTimedOut instead of the server's Code: 159. Max execution time exceeded.

TCP-transport plugins (MySQL, PostgreSQL, MSSQL, SQLite, DuckDB, Oracle, Cassandra, Redis, MongoDB) are unaffected because socket reads block indefinitely.

Fix

Added HttpQueryTimeout to TableProPluginKit (Sendable struct, no protocol changes, no ABI bump). Each HTTP plugin stores one under its existing lock, updates it in applyQueryTimeout, and sets URLRequest.timeoutInterval = configured + 30s grace per request. The 30-second grace ensures the server-side limit fires first with a meaningful error.

Also removed the if timeoutSeconds > 0 short-circuit at three host sites so Settings > Query timeout = 0 ("No limit") now reaches drivers and bounds the transport at the 1-hour resource ceiling instead of silently keeping the 30-second cap.

Plugins changed

Plugin	Status	Notes
ClickHouse	bundled	Per-request applied in executeRaw / executeRawWithParams at call site, not inside buildRequest (kill RPC shares it and keeps its 5s ceiling)
BigQuery	registry	Parallel queryTimeout field alongside existing _queryTimeoutSeconds (polling math untouched)
DynamoDB	registry	Implemented previously-no-op applyQueryTimeout; resource ceiling normalized 60s → 3600s (the old 60s silently truncated long Scan operations)
Etcd	registry	Implemented previously-no-op applyQueryTimeout
CloudflareD1	registry	New applyQueryTimeout override in driver wrapper
LibSQL	registry	New applyQueryTimeout override in driver wrapper

ABI strategy

No currentPluginKitVersion bump. Adding a new public struct to TableProPluginKit doesn't change PluginDatabaseDriver / DriverPlugin witness tables, so the five untouched registry plugins (MongoDB, Oracle, DuckDB, MSSQL, Cassandra) keep loading at version 12.

The five touched registry plugins get TableProMinAppVersion = "0.42.0" in their Info.plist, so an old TablePro build cleanly rejects a newly re-tagged plugin via PluginManager.swift:380 instead of risking a dyld symbol-not-found at runtime.

Verification

• xcodebuild ... build: BUILD SUCCEEDED
• swiftlint lint --strict: 0 violations across 868 files
• HttpQueryTimeoutTests: 8/8 passed (default + grace + zero + negative + clamp + statics + URLRequest assignment)

Post-merge release flow

• Bundled ClickHouse ships with TablePro 0.42.0.
• Re-tag the 5 registry plugins individually after merge: plugin-bigquery-v*, plugin-dynamodb-v*, plugin-etcd-v*, plugin-cloudflare-d1-v*, plugin-libsql-v* (CI fires once per multi-tag push, push one at a time).
• Update plugins.json in TableProApp/plugins with new version + downloadURL + both arch sha256 for each.

Out of scope

• Live re-apply when user changes Settings > Query timeout on an open session. Today the help text says "Applied to new connections." and that stays accurate.
• Per-connection timeout override in the connection form.
• BigQuery polling math (_queryTimeoutSeconds * 2 retry budget): own bug, separate fix.
• Resource ceiling above 1h for compaction-style very-long jobs: defaults key, future work.

---

Plan: velvety-bouncing-wand.md (local artifact; ask if you want the full text inline)

🤖 Generated with Claude Code