SNOW-1806123: Context isn't being propagated into authenticateWithConfig

[aldld]

Please answer these questions before submitting your issue.
In order to accurately debug the issue this information is required. Thanks!

1. What version of GO driver are you using?
   1.11.2

2. What operating system and processor architecture are you using?
   N/A

3. What version of GO are you using?
   1.22

4.Server version:* E.g. 1.90.1
You may get the server version by running a query:

SELECT CURRENT_VERSION();

5. What did you do?

We've run into some cases where some of our customers are having issues establishing Snowflake database connections. In particular, we set a context deadline of e.g. 120 seconds, however, these calls end up running for much longer than they should be (around 354 seconds) before failing.

In the source code for OpenWithConfig, I see that we make a call to authenticateWithConfig(sc). In particular, we don't pass in the incoming ctx. Instead, we end up using sc.ctx, which gets set to context.Background() in buildSnowflakeConn. Am I missing something, or does this mean that there are places where the driver simply doesn't respect context deadlines?

7. What did you expect to see?

Calls to OpenWithConfig should respect the incoming context deadline.

8. Can you set logging to DEBUG and collect the logs?

   https://community.snowflake.com/s/article/How-to-generate-log-file-on-Snowflake-connectors

   Before sharing any information, please be sure to review the log and remove any sensitive
   information.

[aldld]

Looking bit more broadly, is there any reason why we even store a context on the snowflakeConn, if it's just going to be context.Background()? If the goal is to store a context that can be reused but is detached from the initial request's context, something like context.WithoutCancel(ctx)` might be more appropriate.

One additional consequence is that because sc.ctx is missing values from any outside context, and because it's used in a lot of logging calls, that means that any logging hooks that callers have registered won't have access to context values that are set outside of the driver. In those cases though, ideally we'd be using the context provided on the individual QueryContext or ExecContext call, not one that's stored from when the connection was first established.

[sfc-gh-dszmolka]

thank you Eric, we'll take a look

[sfc-gh-dszmolka]

should be fixed with #1247 ; which will be rolled out with the next release

[sfc-gh-pfus]

Actually it will be fully fixed in two PRs:
#1247 - fixes propagating context across auth request, but not in closing request. So if you set up timeout or cancel on auth, it will be taken into consideration, but during deleting session these cancellations or timeouts will be ignored.
#1248 - introduces DriverContext implementation. According to docs it only changes that DSN is parsed only once, but the reality is that it changes that during authentication context is taken into account when using sql.Open() instead of sql.OpenDB().