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

🐛 Slack source connector: do not give up retry attempts if there is 429 error #5708

Merged
merged 3 commits into from
Sep 2, 2021

Conversation

avida
Copy link
Contributor

@avida avida commented Aug 27, 2021

What

Part of fix for #5683

How

Describe the solution

Recommended reading order

  1. x.java
  2. y.python

Pre-merge Checklist

Expand the relevant checklist and delete the others.

New Connector

Community member or Airbyter

  • Community member? Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • docs/SUMMARY.md
    • docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
    • docs/integrations/README.md
    • airbyte-integrations/builds.md
  • PR name follows PR naming conventions
  • Connector added to connector index like described here

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • Credentials added to Github CI. Instructions.
  • /test connector=connectors/<name> command is passing.
  • New Connector version released on Dockerhub by running the /publish command described here

Updating a connector

Community member or Airbyter

  • Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Changelog updated in docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
  • PR name follows PR naming conventions
  • Connector version bumped like described here

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • Credentials added to Github CI. Instructions.
  • /test connector=connectors/<name> command is passing.
  • New Connector version released on Dockerhub by running the /publish command described here

Connector Generator

  • Issue acceptance criteria met
  • PR name follows PR naming conventions
  • If adding a new generator, add it to the list of scaffold modules being tested
  • The generator test modules (all connectors with -scaffold in their name) have been updated with the latest scaffold by running ./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates then checking in your changes
  • Documentation which references the generator is updated as needed.

@github-actions github-actions bot added the area/connectors Connector related issues label Aug 27, 2021
Copy link
Contributor

@Zirochkaa Zirochkaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm.
#5697 may be related.

@avida avida requested a review from sherifnada August 30, 2021 13:39
@avida avida linked an issue Aug 30, 2021 that may be closed by this pull request
follow the rules and evaluate delay given by "Retry-After" header.
Do not give up retry attempts in case of 429 error.
"""
return True
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand that when we receive 429 errors, we will always make a sleep for code and one more try for current request. Perhaps it is worth adding, if not the number of retries for one request, then the maximum time, so that an infinite time loop does not turn out? WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sense, updated PR

# own retry counter based on response type.
return None

def should_retry(self, response: requests.Response) -> bool:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little worried about introducing infinite retry here. can we just raise number of retries to 20 or something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you right, added time limit on 429 retry attempts

return True
self.retry_attempts += 1
# In case response is not 429 follow standrad retry logic but implement own retry counter.
return self.retry_attempts <= self.max_retry_attempts and super().should_retry(response)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this ever reset? I think this currently monotonically increases this counter which is not the desired behavior

Copy link
Contributor Author

@avida avida Aug 31, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it being reset in should_retry function. This is tested on test_slack_stream_backoff_500 test case.

request_started_at = None

@property
def max_retries(self) -> Union[int, None]:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resetting some side variables based on accessing a property is very hacky/non-obvious and could result in incorrect behavior.

Is there any reason not to just increase retries a lot? e.g: max_retries = 20 and call it a day? is there a need for all the extra logic?

We could implement the thing you are trying to do here correctly by first implementing https://github.com/airbytehq/airbyte/issues/2762, but the current approach is using the retry methods incorrectly

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sherifnada Done, just increased max retry attempts

@avida avida changed the title Slack source connector: do not give up retry attempts if there is 429 error 🐛 Slack source connector: do not give up retry attempts if there is 429 error Sep 1, 2021
@avida avida merged commit 19c8efd into master Sep 2, 2021
@avida avida deleted the drezchykov/5683-slack-fix branch September 2, 2021 06:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/connectors Connector related issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Source Slack: hitting max retries
5 participants