- Notifications
You must be signed in to change notification settings - Fork 4.9k
Source Github: Retry connection using HTTPAdapter #8518
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
Source Github: Retry connection using HTTPAdapter #8518
Conversation
| /test connector=connectors/source-github
|
| /test connector=connectors/source-github
|
| /test connector=connectors/source-github
|
| /test connector=connectors/source-github
|
| /test connector=connectors/source-github
|
keu left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
| /publish connector=connectors/source-github
|
* retry connection with Github using HTTPAdapter * updated the connector version * updated source def and spec yaml Co-authored-by: Auganbay <auganenu@gmail.com>
What
Resolves #8285
After long sleep the connector tries to send request by resetting the connection, then http.client.RemoteDisconnected error is raised, because Github closes the connection without any response.
The issue is descibed here
Raised
requests.exceptions.ConnectionErroris handled by Default backoff handler, then we sleep 5 seconds.How
We can configure
HTTPAdapteras described here to retry if connection is closed:In
GithubStreamclass's init method:max_retries– (from the urllib3 doc) The maximum number of retries each connection should attempt. Note, this applies only to failed DNS lookups, socket connections and connection timeouts,never to requests where data has made it to the server. By default, Requests does not retry failed connections.
After connection-related errors it retries to connect again.
Logs after proposed solution
Retries should succeed to establish a new connection.
ConnectionErrorwill not be propagated to the default backoff handler, so we can continue without sleep there.Recommended reading order
source_github/streams.py