Skip to content

Incrementing retries should possibly not pass Response #349

Description

@bjester

suggestion: response is always None at this point, and passing it is the risky part of the plumbing.

It's reset to None at the top of each loop iteration and only assigned on the success path, so the except branch can only ever pass response=None_should_retry then falls through to response = e.response anyway. That makes the parameter dead.

It's also a duck-typing trap: Retry.increment and retries.sleep expect a urllib3.response.HTTPResponse and call get_redirect_location(), .status, and (on urllib3 1.26, permitted by the new floor) .getheader("Retry-After"). A requests.Response has none of those. Today the truthiness guards short-circuit because all three members of _RETRY_REQUEST_EXCEPTIONS are raised without a response attached — but any future change that surfaces a retryable RequestException carrying one turns a would-be retry into AttributeError, escaping the except MaxRetryError handler as an unrelated error type.

Passing response=None explicitly (the retry decision is already driven entirely by exception type) removes both the dead parameter and the trap.

Originally posted by @rtibblesbot in #348 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions