lakeops-org/queryflux

Summary Confirm that a single dispatch takes one atomic LiveConfig snapshot, so a Postgres-driven config reload can't be observed half-applied within one query's routing decision. Context QueryFlux reloads routing + cluster config from Postgres on an interval and immediately on write (dynamic config reload, CHANGELOG 0.3.0). A single request's handling reads several pieces of config: the router chain, routingFallback, cluster-group membership, capacity limits (maxRunningQueries / maxQueuedQueries), and health/strategy config. Concern If those reads each go through a separately-swapped Arc (or re-read a shared store) rather than one snapshot captured at request start, a reload landing mid-decision could mix old and new config for the same query — e.g. route using the old chain to a group that the new config just resized or removed, or evaluate capacity against a stale limit. Symptoms would be rare, load-dependent, and hard to reproduce. Ask Verify the dispatch path (crates/queryflux-

Summary The ADBC adapter creates a connection sub-pool per end-user identity for tokenExchange / passthrough (Snowflake). There appears to be no idle eviction or cap on the number of sub-pools. Context crates/queryflux-engine-adapters/src/adbc/mod.rs — per-identity connection pooling was added for Snowflake ADBC tokenExchange (#166) and passthrough, so that USE ROLE / USE WAREHOUSE / USE SCHEMA state doesn't leak across a shared pooled connection. Problem In a deployment with many distinct end users (identity-aware routing, per-user passthrough), the number of live sub-pools grows with the number of users seen since process start. Without an idle TTL or LRU bound this is an unbounded resource: file descriptors, Snowflake sessions, memory. Long-lived proxy processes would accumulate sub-pools for users who queried once hours ago. Ask Confirm current behaviour (is there any eviction?). Add an idle-timeout + max-sub-pool-count (LRU) bound, configurable, with sensible defaults. Emit a g

Summary Time a query spends queued behind cluster capacity limits is not persisted, so the poll handler and client-visible timings omit it. Context crates/queryflux-frontend/src/dispatch.rs:593: // TODO: persist queue_duration_ms so the poll handler can include it Problem QueryFlux does proxy-side queueing when a cluster group is at maxRunningQueries. That wait is part of the latency the proxy adds, but: The poll response / stats show execution time, not queue wait. Query history therefore under-reports end-to-end latency contributed by QueryFlux. Operators can't distinguish "backend is slow" from "we were parked in the QueryFlux queue for 4s", which is exactly the signal needed to size maxRunningQueries / maxQueuedQueries. Ask Persist queue_duration_ms on the query record (schema + crates/queryflux-persistence/src/query_history.rs). Include it in the poll handler response and in Studio's query detail / timing view. Consider a queryflux_queue_wait_seconds histogram if not already p

Documentation area Website Guides — new dedicated page (not the architecture frontend reference). Connection snippets today live in: Getting started (ports + one curl smoke test) Docs overview (typical-clients table only) Per-frontend architecture pages: Trino HTTP, PostgreSQL wire, MySQL wire, Flight SQL, Snowflake (1–2 CLI/Python snippets each) Example READMEs under examples/ There is no single user-facing “how do I connect this client” page in the Guides sidebar. What is unclear or incorrect? A practitioner who already has QueryFlux running still has to hunt across architecture docs to learn: which frontend/port to point a given client at the exact CLI flags, JDBC/ODBC URL, and Python/Go connect call auth headers vs username/password vs Bearer token protocol gotchas that make otherwise-standard clients fail (TLS declined, MySQL --ssl-mode=DISABLED, Postgres simple-query only, Snowflake protocol=http / --insecure, Flight SQL plaintext gRPC) Architecture pages correctly de

Documentation area Root README.md badge row: <img src="https://img.shields.io/github/downloads/lakeops-org/queryflux/total?style=for-the-badge&logo=github&logoColor=white&label=downloads" alt="GitHub release downloads" /> That is the shields.io GitHub downloads endpoint. It currently renders 0. What is unclear or incorrect? The badge is the wrong metric for how QueryFlux is actually distributed. github/downloads/.../total sums attached GitHub Release asset download_count values. QueryFlux releases (queryflux-v0.3.0, v0.2.0, v0.1.2) have no uploaded assets — only GitHub's auto-generated source zip/tarball, which GitHub does not count. The API therefore always returns 0: gh api repos/lakeops-org/queryflux/releases --jq '[.[].assets | length] | add' # 0 People pull the image from GHCR (ghcr.io/lakeops-org/queryflux, published by .github/workflows/release.yml / docker-publish-tag.yml). The package page reports a real number: GHCR package: Total downloads ≈ 1.58K Confirmed via ghcr-ba