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

Use cached remote config on network failure #4709

Merged
merged 1 commit into from
Sep 8, 2017

Conversation

kristjan
Copy link
Contributor

@kristjan kristjan commented Sep 7, 2017

If your configuration provides a URI to inherit_from, the locally
cached file is stale, and you are offline, then running RuboCop would
crash with an error like:

Failed to open TCP connection to example.com:443 (getaddrinfo:
nodename nor servname provided, or not known)

Since we do have a cached config, we can use it, and you can still run
cops without having to wait for the network to be available again.

Effectively, this behaves the same as if the network were accessible,
but the configuration file has not been modified.

If the file has never once been cached, the result is a different crash
reporting that the cached file does not exist. This may be confusing and
could be handled better, but is no worse than RuboCop's behavior when
you specify a nonexistent configuration file.


Before submitting the PR make sure the following are checked:

  • Wrote good commit messages.
  • Commit message starts with [Fix #issue-number] (if the related issue exists).
  • Used the same coding conventions as the rest of the project.
  • Feature branch is up-to-date with master (if not - rebase it).
  • Squashed related commits together.
  • Added tests.
  • Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
  • All tests(rake spec) are passing.
  • The new code doesn't generate RuboCop offenses that are checked by rake internal_investigation.
  • The PR relates to only one subject with a clear title
    and description in grammatically correct, complete sentences.
  • Updated cop documentation with rake generate_cops_documentation (required only when you've added a new cop or changed the configuration/documentation of an existing cop).

Copy link
Collaborator

@jonas054 jonas054 left a comment

Choose a reason for hiding this comment

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

Seems like a good idea.

@@ -40,11 +43,13 @@ def request(uri = @uri, limit = 10, &block)
end

handle_response(http.request(request), limit, &block)
rescue SocketError
handle_response(NetworkInaccessible.new, limit, &block)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do you really need the new NetworkInaccessible class, or could you just use the SocketError object?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nah, it's not necessary. It provides some abstraction if there are more cases to deal with than just SocketError, but I haven't seen others yet.

end

def handle_response(response, limit, &block)
case response
when Net::HTTPSuccess, Net::HTTPNotModified
when Net::HTTPSuccess, Net::HTTPNotModified, NetworkInaccessible
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't totally happy with this list containing both HTTPResponses and *Errors, but it was the simplest path. Any other ideas?

After the rescue on L46, we do have the option of just doing nothing, but I like handle_response being applied consistently.

@Drenmi
Copy link
Collaborator

Drenmi commented Sep 7, 2017

Great addition! The failing spec looks like an intermittent one. Likely concurrency problem because of parallel tests. No need to worry about that one.

@kristjan
Copy link
Contributor Author

kristjan commented Sep 7, 2017

@Drenmi Ah that's a relief, thanks :) I figured it was unrelated, but didn't have an explanation.

@kristjan
Copy link
Contributor Author

kristjan commented Sep 7, 2017

Removed NetworkInaccessible. We can squash before merge, but I left the commit path there for now to avoid messing with commentary.

Copy link
Collaborator

@jonas054 jonas054 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!

If your configuration provides a URI to `inherit_from`, the locally
cached file is stale, and you are offline, then running RuboCop would
crash with an error like:

    Failed to open TCP connection to example.com:443 (getaddrinfo:
    nodename nor servname provided, or not known)

Since we do have a cached config, we can use it, and you can still run
cops without having to wait for the network to be available again.

Effectively, this behaves the same as if the network were accessible,
but the configuration file has not been modified.

If the file has never once been cached, the result is a different crash
reporting that the cached file does not exist. This may be confusing and
could be handled better, but is no worse than RuboCop's behavior when
you specify a nonexistent configuration file.
@kristjan kristjan force-pushed the offline_network_config branch from 1e890dd to 2d686a5 Compare September 8, 2017 04:41
@bbatsov bbatsov merged commit a7b8c1b into rubocop:master Sep 8, 2017
@bbatsov
Copy link
Collaborator

bbatsov commented Sep 8, 2017

Nice improvement! 👍

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

Successfully merging this pull request may close these issues.

4 participants