HI @kapa.ai, we've recently deployed a new airbyte 1.8.5 instance, with a postgres DB that's backup-ed and restored from an old deployment. In the server, I am able to navigate and see the list of Sources and Destinations, as well as inspect the connections associated with a particular source. However, in the main connections page, I am unable to see any connections as the page is indefinitely loading connections. Checking the Network of the page does show that it's hitting

list_minimal

successfully (returning 200 every time). What might be the reason for the list of connections loading to take forever?

Thinking completed Based on the knowledge sources, there are a few likely causes for this specific symptom (connections page loading indefinitely while

list_minimal

returns 200). Most Likely Cause: Gateway/Load Balancer Timeout on the Connections Query A very similar issue was reported on Airbyte 1.8.3 with a large number of connections. The root cause was that the backend query powering the connections page took long enough to trigger a gateway timeout on the load balancer, even though individual API calls like

list_minimal

completed fine. The page would either appear blank or spin indefinitely. > "I found out that the query for the connections (even though they're supposed to be paginated?) takes long enough that it triggers the gateway timeout on our load balancer (ALB). Increasing the idle timeout threshold fixed it." [Connections issue 1.8.x] What to check: 1. How many connections are in the restored database? Workspaces with a large number of connections (e.g., 400+) are more prone to this. Check your load balancer / ingress timeout settings and increase the idle timeout. 2. Check your ingress/proxy timeout configuration. If you're behind nginx or an ALB, look for annotations likenginx.ingress.kubernetes.io/proxy read timeout "600" nginx.ingress.kubernetes.io/proxy-send-timeout: "600"or the equivalent for your load balancer. Secondary Consideration: Restored Database State Since you restored from an old deployment, it's worth checking whether the database schema migration completed cleanly. A migrated database can sometimes leave Airbyte in a partially broken state, particularly for workload dispatching and query performance. [Migration hang issue] Also Worth Checking • Database query performance: If the restored Postgres DB is under load or has stale statistics, the connections list query may be slow. Running

ANALYZE

on the Airbyte database tables may help. • Server logs: Check the

airbyte-server

pod/container logs for any

DataAccessException

or slow query warnings at the time you load the connections page. The fact that you can navigate to sources, destinations, and even inspect a connection from a source page (which are lighter queries) but cannot load the main connections list (a heavier aggregated query) strongly points to a timeout or performance issue on the connections list query specifically. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Hmm @kapa.ai, do you think a vacuum analyze would help? Given that I just restored the db

Thinking completed I should be transparent here: the knowledge sources I have available do not explicitly mention

VACUUM ANALYZE

as a solution for this type of issue, so I can't confidently confirm or deny it based on those sources. That said, in my previous response I suggested it as a general PostgreSQL best practice after a restore — that was my own reasoning rather than something drawn from the Airbyte knowledge sources, and I should have been clearer about that distinction. What the knowledge sources do point to as the more likely culprit in your specific case is a timeout on the connections list query, particularly when the workspace has a large number of connections: > "I found out that the query for the connections (even though they're supposed to be paginated?) takes long enough that it triggers the gateway timeout on our load balancer." [Connections issue 1.8.x] I'd suggest prioritising checking and increasing your load balancer / ingress idle timeout first, since that's the documented fix for the exact same symptom (indefinitely loading connections page on 1.8.x). If after doing that the page still loads slowly, then database-level tuning (like

VACUUM ANALYZE

) may be worth exploring — but that would be general PostgreSQL advice rather than something Airbyte's documentation specifically recommends. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Thank you for the response @kapa.ai However I am doubtful that timeout is the issue here since I am currently using port-forwarding to access the server UI. Some additional context: • I've checked the network and console on my browser and can see that there is a response payload (just that it's still not being displayed) • I am able to apply filters and get the filtered connection to be displayed (just not the entire list) • I've already run vacuum analyze on the whole db but that has not helped.

Thinking completed I'm sorry, but the provided knowledge sources do not explicitly explain why the UI fails to render the full payload on the connections page despite a successful 200 response and filtering working. However, based on related issues reported in the knowledge sources for Airbyte 1.8.x and frontend rendering behaviors, here are the relevant details: 1. UI Pagination Changes in Airbyte 1.8.x Starting in Airbyte 1.8, Airbyte introduced infinite-scroll pagination across the Connections, Sources, and Destinations pages to handle workspaces with many connections [Airbyte 1.8 Release Notes]. As you scroll, the page is expected to automatically fetch and render additional records. 2. Known Frontend Display / Pagination Issues in 1.8.x There is a documented issue in Airbyte 1.8.x where connections exist in the database and API responses, but the frontend fails to display the full list or get past the initial batch: • In GitHub issue #65131, users reported that after upgrading to 1.8.0+, most connections disappeared from the UI list (e.g., only showing a subset like 20 out of 100+ connections), and scrolling down failed to trigger loading the remaining items [Connections Issue 65131]. • The fact that filtering works in your case (narrowing the dataset down so the UI component can successfully render the smaller subset) strongly points to a frontend rendering/pagination bug in the webapp rather than a database or network timeout issue. 3. Frontend / React Errors In some previous versions, large or idle connection pages have encountered client-side React rendering failures (such as Minified React error #185) [React Error 185 Issue]. Workarounds from the Knowledge Sources While the exact underlying frontend bug for 1.8.5 is not detailed in the sources beyond these reports: • Use search/filters: As you noted, filtering down by specific terms or sources/destinations bypasses the large-batch rendering bottleneck in the UI [Airbyte 1.8 Release Notes]. • Access via Individual Source/Destination pages: Navigating directly through the source or destination details page allows you to view and manage specific connections without loading the entire workspace catalog [Airbyte 1.8 Release Notes]. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Writing down the solution I found for anyone else encountering the same issue: The reason the full connections list was taking so long to load was simply a Postgresql issue; the

jobs

table was using an ineffective index, so for each connection, it was looking through the entire

jobs

table to find the latest sync for a connection (which it will then repeat for all other connections). This is what I did: 1. Run EXPLAIN (ANALYZE, BUFFERS, TIMING) on the query that loads the connections list 2. Identified that

jobs

was taking forever to load 3. Created a suitable composite index 4. Updated via ANALYZE jobs 5. Et voila!