choksi2212 opened a new pull request, #4497:
URL: https://github.com/apache/iggy/pull/4497
## Which issue does this PR address?
Closes #4491
## Rationale
The Rust, Node and C# SDKs all accept `iggy://` connection strings; the Go
SDK had no parser, so Go users built the TCP options by hand. This adds
`ParseConnectionString` per the issue spec, returning the existing options from
`tcp_core.go` so the result drops straight into `client.WithTcp`.
## What changed?
- New `foreign/go/client/connection_string.go` with `func
ParseConnectionString(connectionString string) ([]tcp.Option, error)`.
- Accepts `iggy://` and `iggy+tcp://`; other `iggy+<transport>` schemes are
rejected.
- Credentials: `username:password` or a single personal access token before
the `@`, wired into `WithAutoLogin` via `NewUsernamePasswordCredentials` /
`NewPersonalAccessTokenCredentials`. No new credential or TLS types were added.
- Host: `host:port` and bracketed IPv6 (`[::1]:8090`), validated with
`net.SplitHostPort` plus a u16 port parse.
- Query options follow the grammar shared with the Node SDK
(`client.connection-string.ts`): `tls=true|false`, `tls_domain`, `tls_ca_file`
are applied via `WithTLS`/`WithTLSDomain`/`WithTLSCAFile`;
`reconnection_retries`, `reconnection_interval`, `reestablish_after`,
`heartbeat_interval` and `nodelay` are validated for compatibility and then
ignored, because the Go client takes reconnect, heartbeat and nodelay behavior
from its own defaults. Unknown options and malformed values (`tls=maybe`,
`reconnection_retries=three`, `reconnection_interval=garbage`) are rejected, so
a connection string is either valid everywhere or nowhere.
- Errors reuse the SDK sentinels: `ierror.InvalidConnectionString{}` and
`ierror.InvalidNumberValue{}`. No error message includes the connection string,
so a rejected password or token never leaks into logs.
## How was it tested?
`go test ./client/ -count=1` — 11 test functions, all passing:
- Valid shapes: default scheme with username:password, explicit
`iggy+tcp://` with a personal access token, bracketed IPv6, port 0 (u16 rule
shared with the other SDKs).
- Behavioral: the issue's acceptance path —
`NewIggyClient(WithTcp(opts...))` connects and logs in against a fake
single-node VSR server, asserting the register frame arrives before the
auth-gated roster read. The same flow runs over TLS with
`tls=true&tls_domain=localhost&tls_ca_file=...` against a TLS-only fake server,
proving the option survives into the client config.
- Rejections: the 27 malformed strings the Node SDK's table rejects, plus
`iggy+quic://`, `iggy+ws://` and non-iggy schemes; also fractional/multi-unit
durations (`0.5s`, `1.005s`, `1h 30m`, `1h30m`, `5sec`) are accepted while `5`
and `garbage` are not, and `reconnection_retries` accepts `unlimited` and u32
values but rejects `4294967296`.
- Secrets: no error message contains the password or token from a rejected
string.
- Negative control: with `connection_string.go` removed, the test file fails
to compile (`undefined: ParseConnectionString`), confirming the feature is new.
- Full suite: `go test ./... -count=1 -race` green across the module
(client, tcp, errors, codec, command, hash, util, tests); `go vet ./...` clean;
`gofmt` clean; `go mod tidy` produces no diff. The only failure in a plain `go
test ./...` on this Windows checkout is `internal/vsr` `TestProtocolParity_*`,
which fails identically on pristine master here because the CRLF checkout
breaks the Rust-source regexes — unrelated to this change, and CI (Linux) is
unaffected.
## Documentation
The package-level doc comment on `ParseConnectionString` documents the
accepted shapes and the cross-SDK grammar, including which options are ignored
and why.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
