fix(sdk): allow hostnames in server address configuration by felixfaisal · Pull Request #2923 · apache/iggy

felixfaisal · 2026-03-12T17:14:54Z

Which issue does this PR close?

Rationale

Server address validation previously required a literal socket address, preventing the use of DNS hostnames. This change allows hostnames (e.g., localhost:8080) in addition to IP addresses.

What changed?

Server address validation previously relied on SocketAddr parsing, which only accepts literal IP addresses and rejected DNS hostnames (e.g., localhost:8080). This prevented using hostnames when configuring client connections.

Validation now uses ToSocketAddrs, which performs address resolution and returns the list of socket addresses for a given host. TcpStream::connect(...) already performs this resolution internally and attempts to connect to each resolved address.

Local Execution

Passed
Pre-commit hooks ran

AI Usage

If AI tools were used, please answer:

Which tools? ChatGPT free version
Scope of usage? Write documentations like comments
How did you verify the generated code works correctly?

I built the code using cargo build
I ran the unit tests under TCPConfigBuilder and added an additional unit test, also modifying another
I then ran the server and ran the examples

Can you explain every line of the code if asked? Yup

Signed-off-by: Faisal Ahmed <faisalahmedfarooq46@gmail.com>

codecov · 2026-03-15T11:12:05Z

Codecov Report

❌ Patch coverage is 97.95918% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.81%. Comparing base (411a697) to head (ee78d09).

Files with missing lines	Patch %	Lines
...ebsocket_config/websocket_client_config_builder.rs	0.00%	3 Missing ⚠️
core/common/src/utils/net.rs	99.44%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #2923      +/-   ##
============================================
+ Coverage     71.74%   71.81%   +0.06%     
  Complexity      943      943              
============================================
  Files          1121     1122       +1     
  Lines         93800    93976     +176     
  Branches      71124    71313     +189     
============================================
+ Hits          67301    67485     +184     
+ Misses        23863    23839      -24     
- Partials       2636     2652      +16

Components	Coverage Δ
Rust Core	`72.42% <97.95%> (+0.06%)`	⬆️
Java SDK	`62.30% <ø> (ø)`
C# SDK	`67.43% <ø> (-0.21%)`	⬇️
Python SDK	`81.43% <ø> (ø)`
Node SDK	`91.53% <ø> (+0.21%)`	⬆️
Go SDK	`38.68% <ø> (ø)`

Files with missing lines	Coverage Δ
...figuration/tcp_config/tcp_client_config_builder.rs	`68.04% <100.00%> (+2.44%)`	⬆️
core/common/src/utils/net.rs	`99.44% <99.44%> (ø)`
...ebsocket_config/websocket_client_config_builder.rs	`0.00% <0.00%> (ø)`

... and 26 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

hubcio

hey, thanks for the pr! the intent is solid but there's a fundamental issue with the approach.

to_socket_addrs() calls getaddrinfo() under the hood, which is a synchronous blocking dns lookup. doing this inside build() means config construction now requires network access and can block the thread for seconds if dns is slow. config builders hould be pure/deterministic - th quic builder already gets this right by doing zero address validation in build(). we cannot accept this resolution.

validate the format only (valid host:port structure, port is a valid u16) and leave actual dns resolution to connect time. TcpStream::connect already does resolution internally anyway.

hubcio · 2026-03-21T12:22:38Z

hello @felixfaisal do you plan to continue?

felixfaisal · 2026-03-21T19:11:56Z

hello @felixfaisal do you plan to continue?

Hey @hubcio Sorry for not paying attention here, I was a bit caught up this week, I plan to address the comments and update the logic by tonight or late tomorrow. I mostly agree with your review and will do the changes.

Signed-off-by: Faisal Ahmed <faisalahmedfarooq46@gmail.com>

core/common/src/utils/net.rs

hubcio · 2026-03-23T11:02:31Z

core/common/src/utils/net.rs

+        "".to_string(),
+    ))?;
+
+    if host.is_empty() {


currently only empty host and bare colons are rejected, but any other characters pass - e.g. "!!!:8080" is accepted. would be good to add basic hostname character validation per RFC 952/1123 (alphanumeric, hyphens, dots) to catch obviously invalid addresses at config time rather than deferring everything to DNS resolution at connect time.

Created a separate function, to check if valid IPv4 address and if not check if valid hostname, added a couple of unit tests using claude. ✅
I was thinking if i should use regex or not, and ultimately decided to do it this way.

hubcio · 2026-03-26T11:14:17Z

@felixfaisal both of these comments are not fixed. do you plan do to so?

Signed-off-by: Faisal Ahmed <faisalahmedfarooq46@gmail.com>

hubcio · 2026-03-27T14:08:50Z

core/common/src/types/configuration/tcp_config/tcp_client_config_builder.rs

@@ -105,11 +104,7 @@ impl TcpClientConfigBuilder {
    /// Builds the TCP client configuration.
    pub fn build(self) -> Result<TcpClientConfig, IggyError> {
        let addr = self.config.server_address.trim();


build() validates the trimmed addr but returns self.config with the original untrimmed server_address. if someone passes " localhost:8090 ", validation passes but TcpStream::connect later gets the whitespace-padded string. same issue in websocket_client_config_builder.rs.

fix: self.config.server_address = self.config.server_address.trim().to_string(); before validating.

Updated ✅

hubcio · 2026-03-27T14:08:50Z

core/common/src/utils/net.rs

+/// - Bare IPv6 without brackets (e.g. `::1:8080`) — ambiguous due to colons
+/// - Missing port (e.g. `localhost`)
+/// - Invalid port (e.g. `localhost:abc`, `localhost:65536`)
+pub fn parse_server_address(addr: &str) -> Result<(), IggyError> {


the function name says "parse" but it returns Result<(), IggyError> - it validates, it doesn't parse anything. validate_server_address would be more accurate for a public API, or return a structured type like (host, port) to make the parse useful.

Updated to validate_server_address ✅

hubcio · 2026-03-27T14:08:50Z

core/common/src/utils/net.rs

+            addr.to_string(),
+            "".to_string(),
+        ))?;
+        let ipv6_str = &rest[0..close];


&rest[0..close] - the 0.. is redundant, &rest[..close] is idiomatic.

Updated ✅

hubcio · 2026-03-27T14:08:50Z

core/sdk/src/prelude.rs

    TcpClientReconnectionConfig, Topic, TopicDetails, TopicPermissions, TransportEndpoints,
    TransportProtocol, UserId, UserStatus, Validatable, WebSocketClientConfig,
    WebSocketClientConfigBuilder, WebSocketClientReconnectionConfig, defaults, locking,
+    parse_server_address,


parse_server_address is a low-level validation utility. the builders already call it internally, so SDK consumers rarely need it directly. consider keeping it importable from iggy_common without putting it in the prelude - prelude is for iggy users.

Updated ✅

hubcio · 2026-03-27T14:08:50Z

core/common/src/utils/mod.rs

 pub(crate) mod duration;
 pub(crate) mod expiry;
 pub(crate) mod hash;
+pub mod net;


pub mod net but the sibling modules are pub(crate). since only parse_server_address is re-exported in lib.rs, this could be pub(crate) mod net to match the pattern.

Updated ✅

- Rename function to better reflect its purpose (validation only, not parsing) - Make net module private and only export validate_server_address publicly - Update config builders to normalize and validate server addresses - Remove duplicate address validation from examples Signed-off-by: Faisal Ahmed <faisalahmedfarooq46@gmail.com>

felixfaisal added 2 commits March 12, 2026 22:26

fix(client): allow hostnames in TCP and WebSocket client configuration

5f51fd0

Signed-off-by: Faisal Ahmed <faisalahmedfarooq46@gmail.com>

fix(examples): allow hostnames in TCP server address validation

b515b76

Signed-off-by: Faisal Ahmed <faisalahmedfarooq46@gmail.com>

hubcio requested changes Mar 15, 2026

View reviewed changes

hubcio mentioned this pull request Mar 15, 2026

Rust SDK: Support DNS addresses in client #2882

Open

fix(common): validate server address format without DNS resolution

e63a0ec

Signed-off-by: Faisal Ahmed <faisalahmedfarooq46@gmail.com>

felixfaisal requested a review from hubcio March 23, 2026 04:36

Merge branch 'master' into dev

6a86e94

felixfaisal changed the title ~~fix(client): allow hostnames in server address configuration~~ fix(rust): allow hostnames in server address configuration Mar 23, 2026

hubcio requested changes Mar 23, 2026

View reviewed changes

hubcio changed the title ~~fix(rust): allow hostnames in server address configuration~~ fix(sdk): allow hostnames in server address configuration Mar 26, 2026

Merge branch 'master' into dev

4860fe9

felixfaisal and others added 2 commits March 27, 2026 13:49

feat(net): add RFC 1123 hostname validation and IP address parsing

7f96b5f

Signed-off-by: Faisal Ahmed <faisalahmedfarooq46@gmail.com>

Merge branch 'master' into dev

706ab68

felixfaisal requested a review from hubcio March 27, 2026 13:36

Merge branch 'master' into dev

31c003e

hubcio requested changes Mar 27, 2026

View reviewed changes

felixfaisal requested a review from hubcio March 28, 2026 11:34

Conversation

felixfaisal commented Mar 12, 2026

Which issue does this PR close?

Rationale

What changed?

Local Execution

AI Usage

Uh oh!

codecov bot commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

hubcio left a comment

Choose a reason for hiding this comment

Uh oh!

hubcio commented Mar 21, 2026

Uh oh!

felixfaisal commented Mar 21, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hubcio commented Mar 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codecov bot commented Mar 15, 2026 •

edited

Loading