"databricks.sql.exc.RequestError: Error during request to server" with versions 2.6 onwards

[DJSaunders1997]

When running the quickstart example, I get errors initializing the connection unless I downgrade the package version to 2.5 .

With version 2.6 and above

Error Trace:

$ python example.py
Traceback (most recent call last):
  File "C:\Users\<username>\Databricks_SQL\example.py", line 8, in <module>
    connection = sql.connect(
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv_2\lib\site-packages\databricks\sql\__init__.py", line 50, in connect
    return Connection(server_hostname, http_path, access_token, **kwargs)
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv_2\lib\site-packages\databricks\sql\client.py", line 189, in __init__
    self._session_handle = self.thrift_backend.open_session(
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv_2\lib\site-packages\databricks\sql\thrift_backend.py", line 469, in open_session
    response = self.make_request(self._client.OpenSession, open_session_req)
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv_2\lib\site-packages\databricks\sql\thrift_backend.py", line 398, in make_request
    self._handle_request_error(error_info, attempt, elapsed)
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv_2\lib\site-packages\databricks\sql\thrift_backend.py", line 262, in _handle_request_error
    raise network_request_error
databricks.sql.exc.RequestError: Error during request to server

With downgraded version 2.5

Code works as expected

$ python example.py
Row(id=0)
Row(id=1)
Row(id=2)
Row(id=3)
Row(id=4)
Row(id=5)
Row(id=6)
Row(id=7)
Row(id=8)
Row(id=9)

Environment

It's a pretty standard environment, but for reproducibility:

OS - Windows 10

conda.yml:

name: databrickssqlenv

dependencies:
  - python=3.10
  - pip
  - pip:
    - databricks-sql-connector

Fix

Is there a known fix for this issue? I'd like to use the latest version to enable features such as Azure OAuth.

Thanks

[susodapop]

Sorry for the late response here. I'm not able to reproduce this running any version since 2.5.0. The error you shared doesn't give much detail but I suspect it's a 404 of some kind, rather than a problem with the connector code.

If you add this snippet to the quickstart example you will see the precise logging output from databricks-sql-connector which should give you a better sense of what is wrong:

import logging, sys

logging.getLogger("databricks.sql").setLevel(logging.DEBUG)
logging.getLogger("databricks.sql").addHandler(logging.StreamHandler(sys.stdout))

For example, when I run the quickstart script with this snippet enabled I see the following in my console with connector version 2.7.0

retry parameter: _retry_delay_min given_or_default 1.0
retry parameter: _retry_delay_max given_or_default 60.0
retry parameter: _retry_stop_after_attempts_count given_or_default 30
retry parameter: _retry_stop_after_attempts_duration given_or_default 900.0
retry parameter: _retry_delay_default given_or_default 5.0
Sending request: OpenSession(<REDACTED>)
Received response: TOpenSessionResp(<REDACTED>)
Successfully opened session 01ee1f8b-7630-1b37-a3f6-f498f13b4c43
Sending request: ExecuteStatement(<REDACTED>)
Received response: TExecuteStatementResp(<REDACTED>)
Row(id=0)
Row(id=1)
Row(id=2)
Row(id=3)
Row(id=4)
Row(id=5)
Row(id=6)
Row(id=7)
Row(id=8)
Row(id=9)
Closing session 01ee1f8b-7630-1b37-a3f6-f498f13b4c43
Sending request: CloseSession(<REDACTED>)
Received response: TCloseSessionResp(<REDACTED>)

[susodapop]

I'm closing this for now but feel free to reopen if the issue persists.

[DJSaunders1997]

Hi, thanks for your response.

I've reran the code with the logging and the exact error is still pretty opaque when using 2.7.0 :

$ python example.py
retry parameter: _retry_delay_min given_or_default 1.0
retry parameter: _retry_delay_max given_or_default 60.0
retry parameter: _retry_stop_after_attempts_count given_or_default 30
retry parameter: _retry_stop_after_attempts_duration given_or_default 900.0
retry parameter: _retry_delay_default given_or_default 5.0
Sending request: OpenSession(<REDACTED>)
Error during request to server: {"method": "OpenSession", "session-id": null, "query-id": null, "http-code": 400, "error-message": "", "original-exception": "", "no-retry-reason": "non-retryable error", "bounded-retry-delay": null, "attempt": "1/30", "elapsed-seconds": "0.7410027980804443/900.0"}
Traceback (most recent call last):
  File "example.py", line 14, in <module>
    connection = sql.connect(
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv\lib\site-packages\databricks\sql\__init__.py", line 50, in connect
    return Connection(server_hostname, http_path, access_token, **kwargs)
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv\lib\site-packages\databricks\sql\client.py", line 189, in __init__
    self._session_handle = self.thrift_backend.open_session(
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv\lib\site-packages\databricks\sql\thrift_backend.py", line 506, in open_session
    response = self.make_request(self._client.OpenSession, open_session_req)
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv\lib\site-packages\databricks\sql\thrift_backend.py", line 435, in make_request
    self._handle_request_error(error_info, attempt, elapsed)
  File "C:\Users\<username>\AppData\Local\anaconda3\envs\databrickssqlenv\lib\site-packages\databricks\sql\thrift_backend.py", line 275, in _handle_request_error
    raise network_request_error
databricks.sql.exc.RequestError: Error during request to server

If it is a 404 - can you advice on how I can debug this further?
Thanks

[DJSaunders1997]

I've just read the 2.6.0 release notes, https://github.com/databricks/databricks-sql-python/releases/tag/v2.6.0:
"Note: support for proxies is un-tested in this release. Please report any problems with proxies via GitHub issues.".

I'm running this code on a VM, using a proxy so I suspect this might be the root cause of this issue as version 2.5 still works for me.

Reopening the issue as I'm still having errors, and you've asked for this in the release notes : )

[susodapop]

Thanks for reopening and for more context! We received a community contribution #158 which fixes proxies again. It's not part of an official release (yet) but I've just moments ago pushed out 2.7.1.dev2 which includes the proxy fix.

Can you please pip install databricks-sql-connector==2.7.1.dev2, rerun your script, and see if it now works?

Also, if it doesn't work please be sure to set your log level to DEBUG (the default is INFO) so we can see more of what's going on.

[DJSaunders1997]

I've installed that version, and now the code works as expected : )

$ python example.py
retry parameter: _retry_delay_min given_or_default 1.0
retry parameter: _retry_delay_max given_or_default 60.0
retry parameter: _retry_stop_after_attempts_count given_or_default 30
retry parameter: _retry_stop_after_attempts_duration given_or_default 900.0
retry parameter: _retry_delay_default given_or_default 5.0
Sending request: OpenSession(<REDACTED>)
Received response: TOpenSessionResp(<REDACTED>)
Successfully opened session 01ee217e-2411-1c7c-b151-0204a9ed5827
Sending request: ExecuteStatement(<REDACTED>)
Received response: TExecuteStatementResp(<REDACTED>)
Sending request: GetOperationStatus(<REDACTED>)
Received response: TGetOperationStatusResp(<REDACTED>)
Sending request: GetOperationStatus(<REDACTED>)
Received response: TGetOperationStatusResp(<REDACTED>)
Sending request: GetResultSetMetadata(<REDACTED>)
Received response: TGetResultSetMetadataResp(<REDACTED>)
Sending request: FetchResults(<REDACTED>)
Received response: TFetchResultsResp(<REDACTED>)
Row(id=0)
Row(id=1)
Row(id=2)
Row(id=3)
Row(id=4)
Row(id=5)
Row(id=6)
Row(id=7)
Row(id=8)
Row(id=9)
Sending request: CloseOperation(<REDACTED>)
Received response: TCloseOperationResp(<REDACTED>)
Closing session 01ee217e-2411-1c7c-b151-0204a9ed5827
Sending request: CloseSession(<REDACTED>)
Received response: TCloseSessionResp(<REDACTED>)

I'm happy to reclose this issue, looks like it was a proxy issue after all!

Thanks for your help, I look forward to the release next week : )