sql.connect wrongly reports a timeout when attempting to connect to a non-existing warehouse
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 48/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Pouca atividade
- Stack de tecnologia
- python
- Domínio
- backend-api-design, databases
Direção de pesquisa
Comece em sql.connect e no caminho de retry do ThriftBackend descrito na issue, depois reproduza a tentativa de conexão com um warehouse_id inexistente. Rastreie como respostas 404 repetidas se tornam MaxRetryError e identifique o limite de exceção existente. A tarefa estará concluída quando warehouses inexistentes ou excluídos puderem ser distinguidos de timeouts sem analisar o texto da exceção, enquanto o comportamento normal de retry permanece intacto.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Disclaimer: I am a Databricks employee.
Calling databricks.sql.connect with a non-existing warehouse_id will raise a generic time-out exception, coming from the ThriftBackend.
It's only by digging in the source code that one can find the default of 30(!) retries - which can be set by including _retry_stop_after_attempts_count in sql.connect.
As a user of SQL Client, I'd like to easily make a distinction between a timeout (=unknown circumstances, makes more sense to retry) and a non-existing/deleted warehouse (=hard fact, makes no sense to keep trying to connect).
connection = sql.connect(
server_hostname=server_hostname,
http_path=f"""/sql/1.0/warehouses/{warehouse_id}""",
credentials_provider=_credentials_provider
)
Exception:
HTTPSConnectionPool(host='[xxxx.databricks.com](http://xxxx.cloud.databricks.com/)', port=443):
Max retries exceeded with url: /sql/1.0/warehouses/786786d78562786
(Caused by ResponseError('too many 404 error responses')).
Alternatives considered
- One can add another dependency to the SDK and check if the Warehouse exists. It seems overkill to add the SDK just for that purpose. It really should be part of the connect client.
- One can parse the exception text and apply some heuristics to form an educated guess with the 404 reply. This is hacky and might have too many edge-cases. E.g. calling
/sql/1.0/**warehoses**/xxxxxwould raise the exact same exception.
- Linguagem predominante
- Python
- Estrelas
- 233
- Forks
- 152
- Merge médio
- 21h 5min
- PRs com merge (30d)
- 10
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de databricks/databricks-sql-python
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
Todas as issues de databricks/databricks-sql-python
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 86/100
-
🐛 Bug 🔔 Pending processing
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
jumpserver/jumpserver#17584 ·