Make isError on GitHubConnectorResponseErrorHandler public.

[rozza-sb]

Description

Changes the access modifier on GithubConnectorResponseErrorHandler and subclasses to public. This allows library users to overwrite what constitutes an error for the response, particularly for (secondary) rate limiting.

Relates to #2009, where GithubAbuseLimitHandler is not properly detecting secondary rate limits but users cannot manually override it while the method is package-private. Additionally, the definition of isError under STATUS_HTTP_BAD_REQUEST_OR_GREATER is public, which could imply that this should be public from the start. A future PR will do a fix to the underlying issue, but in the mean time this would allow users to implement their own fix.

Before submitting a PR:

• Changes must not break binary backwards compatibility. If you are unclear on how to make the change you think is needed while maintaining backward compatibility, CONTRIBUTING.md for details.
• Add JavaDocs and other comments explaining the behavior.
• When adding or updating methods that fetch entities, add @link JavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .
• Add tests that cover any added or changed code. This generally requires capturing snapshot test data. See CONTRIBUTING.md for details.
• Run mvn -D enable-ci clean install site "-Dsurefire.argLine=--add-opens java.base/java.net=ALL-UNNAMED" locally. If this command doesn't succeed, your change will not pass CI.
• Push your changes to a branch other than main. You will create your PR from that branch.

When creating a PR:

• Fill in the "Description" above with clear summary of the changes. This includes:
  • If this PR fixes one or more issues, include "Fixes #" lines for each issue.
  • Provide links to relevant documentation on https://docs.github.com/en/rest where possible. If not including links, explain why not.
• All lines of new code should be covered by tests as reported by code coverage. Any lines that are not covered must have PR comments explaining why they cannot be covered. For example, "Reaching this particular exception is hard and is not a particular common scenario."
• Enable "Allow edits from maintainers".

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.02%. Comparing base (d15396f) to head (23981be).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #2127   +/-   ##
=========================================
  Coverage     85.02%   85.02%           
  Complexity     2495     2495           
=========================================
  Files           237      237           
  Lines          7351     7351           
  Branches        388      388           
=========================================
  Hits           6250     6250           
  Misses          871      871           
  Partials        230      230           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gsmet]

FWIW, while I'm not against this patch, I would very much in favor of making the default implementation better. As most people will just use it as is and shoot themselves in the foot.

This patch might be a good way to experiment but it would be nice to contribute back a better default implementation if you come up with one!

[rozza-sb]

@gsmet The main reason for me doing this small patch is more of a preliminary one, as it is a quicker fix that enables the better implementation locally (potentially guided by some documentation), before said implementation is implemented in a future PR. I would also wonder given the usage in GitHubConnectorResponseErrorHandler#STATUS_HTTP_BAD_REQUEST_OR_GREATER where this is already public, whether it is intended to be, or if it is just unintentionally public.

I am not against nixing this PR and writing the better implementation now, if it is felt that this change would lead to bad habits by the users. At least for our use case, it should be possible to do a local patch and build with that source and provide that in the mean time.

[rozza-sb]

Regarding said better implementation, as mentioned in my comment under #2009 there are two potential messages that can be returned that we can check for:

• "You have exceeded a secondary rate limit"
• "You have triggered an abuse detection mechanism"

On a local branch that I had started working on, I have a method that we could extend isError with:

private boolean hasRelevantErrorMessages(GitHubConnectorResponse connectorResponse) throws IOException {
    String content = new String(connectorResponse.bodyStream().readAllBytes(), StandardCharsets.UTF_8).toLowerCase();
    return content.contains("you have exceeded a secondary rate limit") || content.contains("you have triggered an abuse detection mechanism");
}

If the general concept of this seems like an acceptable fix, I'd go on ahead with this and open a PR once I get some time 👍

[bitwiseman]

I'm not completely sure why I made the method internal, but I think @gsmet points in the right direction.

The public override on STATUS_HTTP_BAD_REQUEST_OR_GREATER is a mistake - it should be consistent with the base GitHubConnectorResponseErrorHandler.

The design is as intended, isError() should be internal.

The library only support two types of error handlers externally, "abuse" and "rate limit" and the detection of these types of errors should be implemented centrally in this library not by consumers. The check for whether a certain kind of error handler should fire should be the same for all instance of that type error handler. All "abuse" error handlers should use the same "isError()", all "rate limit" error handlers should use the same "isError()". The only thing that should be implemented by consumers of the library is the what they choose to do about the error - the "onError()" method.

Regarding your proposed solution with string checking:
Generally I approve you suggestion, but you need to do something similar to isServiceDown() method to limit how much of the response you search.

github-api/src/main/java/org/kohsuke/github/GitHubConnectorResponseErrorHandler.java

Lines 74 to 79 in 40f3b4d

	while (hardLineCap > 0 && (line = bufReader.readLine()) != null) {
	if (line.trim().startsWith(UNICORN_TITLE)) {
	return true;
	}
	hardLineCap--;
	}

The check for isError() is run at least once for each attached error handler when a non-success response is returned. This wouldn't be be so bad, except there are a wider range of non-success responses. The checks need to be efficient or they could bog down performance in unexpected ways.

If you want to abstract the helper that searches the first N lines for a list of strings, that's sounds good. Now that I'm thinking about it would probably be more performant to change the loop above to a something that grabs the first 2kb of the response as a string and searches that for each of the error strings, instead doing line by line contains() calls.

You might also look at #1975 for what I think should happen in this area longer term.

[bitwiseman]

@rozza-sb
I'm going to close this PR. Please open a new one for your other proposed change.