Skip to content

Conversation

akihikodaki
Copy link

It makes little sense to emit a warning saying "to use retry middleware" when the user does not request that. Remove the warning.

Resolves #1567


Before the change?

  • It emits a warning saying "to use retry middleware..."

After the change?

  • The warning is gone.

Pull request checklist

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

  • Yes
  • No

Copy link

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

Next, insert `Octokit::Middleware::Retry` before `Octokit::Response::RaiseError`:

```ruby
Octokit.middleware.insert Octokit::Response::RaiseError, Octokit::Middleware::Retry
Copy link
Contributor

Choose a reason for hiding this comment

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

I would think configuring it on the client would be better

Octokit::Client.new(auto_retry: true)

and then in the connection sawyer options you can insert the retry middleware if @auto_retry

conn_opts[:builder].insert(0, *retry_middleware) if @auto_retry

Copy link
Author

Choose a reason for hiding this comment

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

While having a parameter for Octokit::Client.new is more concise, there are a few advantages of explicitly requiring to interact with middleware:

  1. A user can specify additional options.
  2. It is clear that it interacts with middleware.
  3. It is consistent with the suggestion for caching, which follows this section in README.md.

So there is some trade-off. What do you prefer?

Copy link
Contributor

@pbstriker38 pbstriker38 Oct 23, 2024

Choose a reason for hiding this comment

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

What happens if you want one client that retries and another that doesn't. Setting on Octokit.middleware is global.

You probably also want a maintainer to chime in here...

Copy link
Author

Choose a reason for hiding this comment

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

Copy link

👋 Hey Friends, this pull request has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!

@github-actions github-actions bot added the Status: Stale Used by stalebot to clean house label Jul 22, 2025
It makes little sense to emit a warning saying "to use retry middleware"
when the user does not request that. Remove the warning.
Duplicate the default middleware stack so that it won't be modified.
Octokit::Middleware::Retry allows incorporating the retry logic without
relying on the default middleware stack.
No retry middleware is included in Faraday 2.x and retrying requires
Faraday Retry gem. The default middlware stack used to include a retry
middleware only when available, which means the behavior of Octokit
implicitly changes depending on to the Faraday version or the presence
of Faraday Retry gem.

Remove the retry middleware from the default middleware stack to avoid
such an implicit behavioral change.
@akihikodaki
Copy link
Author

Rebased to v10.0.0.

@github-actions github-actions bot removed the Status: Stale Used by stalebot to clean house label Jul 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 👀 In review

Development

Successfully merging this pull request may close these issues.

[BUG]: The type of the dependency on faraday-retry is irritating and unclear.

2 participants