Skip to content

SG-38213 Prevent unexpected retries on error #379

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

carlos-villavicencio-adsk
Copy link
Contributor

@carlos-villavicencio-adsk carlos-villavicencio-adsk commented May 5, 2025

We want to control when python-api does a retry on error.

  • SSLEOFError
  • SSLHandshakeError

On _make_call function.

We don't want to retry on a general exceptions (e.g. Timeout or remote disconnection) because we might send a resource modification request (create, batch create, etc) and we can end up duplicating things.

@carlos-villavicencio-adsk carlos-villavicencio-adsk requested a review from a team May 5, 2025 21:00
Copy link
Contributor

@julien-lang julien-lang left a comment

Choose a reason for hiding this comment

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

Looks good but I am worried we are going to create new regressions with removing that retry.

Did you identify when and why this retry on generic exceptions was introduced?

Comment on lines 3941 to 3944
except Exception as e:
self._close_connection()
if attempt == max_rpc_attempts:
LOG.debug("Request failed. Giving up after %d attempts." % attempt)
raise
LOG.debug(f"Request failed. Reason: {e}")
raise
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we even keep this except block then?
Just for the _close_connection?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here we can catch RemoteDisconected or some other error which I don't remember rn about ClosedConnection or something like that.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand this answer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok let me summarize it: We use this except block for timeout or any other server error. And this is what's been happening with this ticket's context.

@carlos-villavicencio-adsk
Copy link
Contributor Author

Looks good but I am worried we are going to create new regressions with removing that retry.

Did you identify when and why this retry on generic exceptions was introduced?

It seems this concern was already identified before.

If any regression happened, that can help us identify better use cases (and we can always let the customers use the previous versions).

Copy link
Contributor

@julien-lang julien-lang left a comment

Choose a reason for hiding this comment

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

Just 2 minor points, then I'll be happy :)

Comment on lines 3941 to 3944
except Exception as e:
self._close_connection()
if attempt == max_rpc_attempts:
LOG.debug("Request failed. Giving up after %d attempts." % attempt)
raise
LOG.debug(f"Request failed. Reason: {e}")
raise
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand this answer.

Co-authored-by: Julien Langlois <16244608+julien-lang@users.noreply.github.com>
julien-lang
julien-lang previously approved these changes May 7, 2025
Copy link
Contributor

@julien-lang julien-lang left a comment

Choose a reason for hiding this comment

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

LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants