fix: Handle null server address

[blakeli0]

In case of an invalid endpoint such as localhost:-1, the current parsing logic returns null for server address. This PR made server address nullable. And added a null check for the port parsing.

In addition, added a try catch for the whole parsing logic because serviceAddress and serverPort should only be used for obersevability and should not affect regular requests.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the robustness of endpoint parsing by gracefully handling invalid server addresses and ports. It ensures that issues during the parsing of observability-related endpoint details do not impact the core functionality of client requests, improving the overall stability of the system.

Highlights

• Nullability: The resolvedServerAddress method was updated to be nullable, allowing it to return null when an address cannot be parsed.
• Robust Parsing: Added a null check for HostAndPort objects during port parsing to prevent NullPointerExceptions for invalid endpoints.
• Error Handling: The server address and port parsing logic in EndpointContext.build() is now wrapped in a try-catch block, ensuring that parsing errors do not disrupt main client requests, as these values are primarily for observability.
• Test Coverage: A new test case was added to verify that invalid endpoints correctly result in null server address and port.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request enhances the EndpointContext to gracefully handle invalid server addresses and ports by adding null checks, making resolvedServerAddress nullable, and wrapping parsing logic in a try-catch block. A new test case validates this behavior. The reviewer suggests improving the exception handling by catching a more specific exception (e.g., RuntimeException) and adding logging for debugging, as the current broad Exception catch could hide potential issues.

[gemini-code-assist]

Catching a broad Exception and silently swallowing it can hide potential bugs and make debugging difficult. It's better to catch a more specific exception, like RuntimeException, to avoid catching checked exceptions like IOException unintentionally. Additionally, logging the caught exception at a WARNING or DEBUG level is highly recommended to provide visibility into potential configuration issues with endpoints.

Suggested change

	} catch (Exception throwable) {
	// Server address and server port are only used for observability.
	// We should ignore any errors parsing them and not affect the main client requests.
	}
	} catch (RuntimeException throwable) {
	// Server address and server port are only used for observability.
	// We should ignore any errors parsing them and not affect the main client requests.
	// TODO: Add logging for the swallowed exception to aid debugging.
	}