fix(workspace): gracefully handle failing db connections

[juleswritescode]

With this PR, we should now be able to run basic diagnostics, even if the workspace can't connect to the Db. I tested it locally with pg_cli check test.sql and it seems to work.

The basic gist:

Whenever we called WorkspaceServer::update_settings, we would configure the DatabaseConnection for lazy-loading, but eagerly loaded the SchemaCache.

I thought it was weird that we queried the Db in a update_settings call, so I refactored the SchemaCache to be lazy-loaded as well.

For this, I wrapped the whole thing into a SchemaCacheManager which checks if we've already cached the requested PgPool's schema, returning guarded handles to the underlying SchemaCache.

Additional Things

• moved SchemaCacheManager, DbConnection, and the async runtime helpers into their own modules
• DbConnection::get_pool() will now panic if the developer hasn't set the DbConnection options
• the completions handler will now return an empty array if we can't connect to the db
• added an optional conn_timeout_secs config option, which is by default set to 10 seconds
• removed SchemaCache::new(), since that only delegated to its Default impl

[juleswritescode]

all of the below is just moved by a tab, because I removed the if let Some(..) = .. closure

[psteinroe]

Really nice! Thanks for the cleanup too. Left two comments, let's discuss them in the respective threads 🙏🏼

[juleswritescode]

@psteinroe

Regarding the "slowness":

I added a --skip-db flag that will make it such we never connect to any db. The DbConnection.get_pool() will simply return None.

Regarding the timeout:

I tried to add a deferred log to the console, something that would print "Your connection takes longer than expected…" if it takes >=2s – but that required wrapping the app.console in a mutex.

So instead, I added a user_hints vector that collects hints to print just after the diagnostics summary.
(We could reuse this e.g. when a user does not properly separate their statement with newlines for the statement splitter.)

I also added an AtomicBool that indicates whether we were able to get a PgPool. If not, we'll print another hint: "Skipped all checks requiring a database connection".

I'm not 100% happy with the result; especially the bool feels inelegant. So hit me with your feedback!

[psteinroe]

I like the implementation a lot, but the entire user hint story feels like bloat? For now, I think we should either skip this "feedback" entirely or just add it as another "warning" diagnostics? but not sure

[juleswritescode]

I like the implementation a lot, but the entire user hint story feels like bloat? For now, I think we should either skip this "feedback" entirely or just add it as another "warning" diagnostics? but not sure

agree! I thought about adding it as a warning, but I can also see someone setting their CI to fail on "warn" instead of "error" – and a slow db connection shouldn't be the reason for that.

Let's leave it for now; maybe it's a non-issue and most people simply have working connections.

I do think it would be nice if we could output logs during and not only after the traversal, but let's descope that for now.

[juleswritescode]

@psteinroe Also, you're still on vacation for a day, so don't you dare review before tomorrow

[psteinroe]

(I am on German grounds again!)

Lgtm! Just have one comment about the timeout 🙏🏼

[psteinroe]

Not sure, but maybe we can set the default via bpaf?

[psteinroe]

If not, we should add it to the comments.

[juleswritescode]

I played around with using a bpaf fallback, but the partial macro requires that the fallback is wrapped in an Option.

If we want to use display_fallback, we would also need to implement Display for Option<u16>, but we can't because of the Orphan Rule.

A quick fix is to add the fallback to the comment, wdyt?

[juleswritescode]

Ah, we can use the debug representation. Works for me, too.