This repository was archived by the owner on Sep 2, 2025. It is now read-only.
Handle case of 0 connect retries better for HTTP Spark Connections #132
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Thanks for the contribution @danielvdende! This change makes sense. Could you add a changelog entry, and add yourself to the list of contributors? The failing test looks unrelated—seems to be an issue with executing a |
With a default of 0 connect_retries, confusing log messages show up. The logs suggest that a retry is going to be carried out, but it isn't. Also, a sleep is carried out, even if no retries are to happen. This check prevents this from happening.
Contributor
Author
|
Done @jtcohen6 ! Thanks for the swift response 👍 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
resolves #131
Description
With a default of 0 connect_retries, confusing log messages show up. (see example below)
We encountered this while working with Databricks, where we had a cluster that had not been started yet.
The logs suggest that a retry is going to be carried out, but it isn't (because the retry count defaults to 0). Also, a sleep is carried out, even if no retries are to happen. This check prevents this from happening.
Checklist
CHANGELOG.mdand added information about my change to the "dbt next" section.