Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SNOW-1650640: Emit WARNING instead of ERROR for OCSP fail-open message #2044

Closed
colin-rogers-dbt opened this issue Sep 4, 2024 · 3 comments
Assignees
Labels
feature status-fixed_awaiting_release The issue has been fixed, its PR merged, and now awaiting the next release cycle of the connector. status-triage_done Initial triage done, will be further handled by the driver team

Comments

@colin-rogers-dbt
Copy link

What is the current behavior?

When running queries on behalf of our users in dbt Cloud we often see the following ERROR message:

ERROR:snowflake.connector.ocsp_snowflake:WARNING!!! Using fail-open to connect. Driver is connecting to an HTTPS endpoint without OCSP based Certificate Revocation checking as it could not obtain a valid OCSP Response to use from the CA OCSP responder.

While this is often due to DNS issues that our users can address it can also happen transitively. As we run a lot of queries against snowflake these errors can result in a great deal of noise in our logging.

What is the desired behavior?

Can this instead be emitted as a warning? It would be more intuitive for our users and de-clutter our logging (along with our log based metrics).

How would this improve snowflake-connector-python?

Making it easier to interpret/use snowflake-connector logging.

References and other background

No response

@github-actions github-actions bot changed the title Emit WARNING instead of ERROR for OCSP fail-open message SNOW-1650640: Emit WARNING instead of ERROR for OCSP fail-open message Sep 4, 2024
@sfc-gh-dszmolka sfc-gh-dszmolka self-assigned this Sep 5, 2024
@sfc-gh-dszmolka sfc-gh-dszmolka added status-triage Issue is under initial triage and removed needs triage labels Sep 5, 2024
@sfc-gh-dszmolka sfc-gh-dszmolka added status-pr_pending_merge A PR is made and is under review status-triage_done Initial triage done, will be further handled by the driver team and removed status-triage Issue is under initial triage labels Sep 5, 2024
@sfc-gh-dszmolka
Copy link
Contributor

hi - thanks for raising this request, it's quite reasonable considering we indeed continue to connect even though OCSP could not be performed. Created a #2045 in attempt to change the loglevel to warning.

However, as you are already aware that the presence of this warning message signals permanent/temporal inability to reach OCSP endpoints, optimally the root cause of such issues needs to be investigated and eliminated in the runtime environment. Mainly because if OCSP checks cannot be performed, it inevitably will mean timeouts and retries to the same endpoints, which means unnecessary delays possibly introduced into the particular connection's setup time.

Anyways, it should be emitted as warning i agree, and not an error

@sfc-gh-dszmolka sfc-gh-dszmolka added status-fixed_awaiting_release The issue has been fixed, its PR merged, and now awaiting the next release cycle of the connector. and removed status-pr_pending_merge A PR is made and is under review labels Sep 6, 2024
@sfc-gh-dszmolka
Copy link
Contributor

change is merged and will be included in the next release

@sfc-gh-dszmolka
Copy link
Contributor

change released with v3.12.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature status-fixed_awaiting_release The issue has been fixed, its PR merged, and now awaiting the next release cycle of the connector. status-triage_done Initial triage done, will be further handled by the driver team
Projects
None yet
Development

No branches or pull requests

2 participants