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

netty: return status code unavailable when netty channel has unresolved InetSocketAddress #7023

Merged
merged 3 commits into from May 21, 2020

Conversation

reggiemcdonald
Copy link
Contributor

Closes #6954

Bug fix to return status code UNAVAILABLE when a netty channel has an unresolved InetSocketAddress

  • Adds check in netty utils
  • Updates unit test for netty utils
  • Adds test case to ensure status code UNAVAILABLE is returned

…th unresolved InetSocketAddresses

This commit adds a check for UnresolvedAddressException in netty Utils. This change was made to ensure that netty channels built from an unresolved InetSocketAddress would return Status UNAVAILABLE instead of UNKNOWN.
@creamsoup creamsoup requested a review from ejona86 May 8, 2020 21:06
@creamsoup creamsoup added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label May 8, 2020
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label May 8, 2020
public void channelHasUnresolvedHostname() throws Exception {
server = null;
ManagedChannel channel = NettyChannelBuilder
.forAddress(new InetSocketAddress("invalid", 1234))
Copy link
Member

Choose a reason for hiding this comment

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

InetSocketAddress.createUnresolved()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ahh missed this in the docs. Thanks!

This commit addresses PR feedback to make NettyTransportTest.channelHasUnresolvedHost more lightweight.
Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

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

Only thing that actually matters is the try-finally, and I can even live with it. I'll give you some time to fix it, but if it looks like it'll take more than a day or two I'd be happy to merge as-is. (I'm not saying that to rush you, just to say how it doesn't matter much.)

.setChannelLogger(logger), logger);
Runnable runnable = transport.start(new ManagedClientTransport.Listener() {
final Throwable failTestException =
new Throwable("transport should have failed and shutdown but didnt");
Copy link
Member

Choose a reason for hiding this comment

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

super-nit: this can just be created within transportReady() itself. I would be fine with merging it like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

assertEquals(Status.Code.UNAVAILABLE, status.getCode());
assertTrue(status.getCause() instanceof UnresolvedAddressException);
assertEquals("unresolved address", status.getDescription());
} catch (Exception e) {
Copy link
Member

Choose a reason for hiding this comment

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

This is cleaner and clearer as a try-finally.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

try {
Status status = future.get();
assertEquals(Status.Code.UNAVAILABLE, status.getCode());
assertTrue(status.getCause() instanceof UnresolvedAddressException);
Copy link
Member

Choose a reason for hiding this comment

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

You can leave it as-is, but I'll note that assertTrue/assertFalse commonly produce poor error messages if they fail.

This is one of the biggest reasons using Truth can be nice. With Truth, this would be assertThat(status.getCause()).isinstanceof(UnresolvedAddressException.class) (assertThat is typically a static import from the Truth class). Then if it fails, instead of saying "expected true but was false" it can say "expected UnresolvedAddressException but was SomeOtherException" which can greatly aid debugging. It's possible to do that with the JUnit assertion, but you have to create a string and pass it as the first argument. Something to consider for the future.

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 like that a lot better! Change made

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label May 11, 2020
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label May 11, 2020
This commit addresses a PR comment to make the try-catch a try-finally. Swaps assertTrue to Truth.assertThat.
@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label May 11, 2020
@grpc-kokoro grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label May 11, 2020
@reggiemcdonald
Copy link
Contributor Author

Just wanted to check whether this PR needs any additional changes, or if its ready to merge?

@creamsoup creamsoup merged commit 4081363 into grpc:master May 21, 2020
@creamsoup
Copy link
Contributor

oops sorry about the delay. I blame kokoro
anyways, merged thanks @reggiemcdonald

@ejona86
Copy link
Member

ejona86 commented May 21, 2020

Yep. I needed kokoro to run and then it got buried. Thanks for pinging it!

@reggiemcdonald
Copy link
Contributor Author

No problem! 🙂

dfawley pushed a commit to dfawley/grpc-java that referenced this pull request Jan 15, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Receiving Unknown Status code on hostname with InetSocketAddres
4 participants