apache/iggy

The Rust client parses iggy:// connection strings (core/common/src/types/configuration/auth_config/connection_string.rs), and the Node and C# SDKs do too. The Java SDK has no parser, so Java users set host, port and credentials by hand. What to do Add public IggyTcpClientBuilder fromConnectionString(String connectionString) to foreign/java/java-sdk/src/main/java/org/apache/iggy/builder/TcpClientBuilder.java. Accept iggy:// and iggy+tcp://, with user:password@host:port and tls=true as a query option. Reject other schemes such as iggy+quic://. Follow parseConnectionString in foreign/node/src/client/client.connection-string.ts. Delegate to the existing builder methods: blocking().host(...).port(...).credentials(...).tls(...). Username and password only: the Java builders have no personal access token login, and adding one is out of scope. Add tests next to IggyTcpClientBuilderTest.java for valid strings, tls=true and rejected input. Done when Iggy.tcpClientBuilder().fromConnectionString

The Rust client parses iggy:// connection strings (core/common/src/types/configuration/auth_config/connection_string.rs), and the Node and C# SDKs do too. The Go SDK has no parser, so Go users build the TCP options by hand. What to do Add func ParseConnectionString(connectionString string) ([]tcp.Option, error) in a new file, foreign/go/client/connection_string.go. Accept iggy:// and iggy+tcp://, with user:password@host:port or a personal access token before the @, and tls=true as a query option. Reject other schemes such as iggy+quic://. Follow parseConnectionString in foreign/node/src/client/client.connection-string.ts. Build the result from the existing options in foreign/go/client/tcp/tcp_core.go: WithServerAddress, WithAutoLogin with NewUsernamePasswordCredentials or NewPersonalAccessTokenCredentials, and WithTLS. Do not add new credential or TLS types. Add a table test in foreign/go/client/connection_string_test.go for valid strings, tls=true, both credential types, and rejected

Split from #4452. Problem When a command fails, main returns the error (core/cli/src/main.rs:359), so Rust prints its Debug value. For example, iggy ping against a stopped server ends with: Error: IggyClient(SdkError(CannotEstablishConnection)) The top-level Display is only a label, for example "Iggy client error", so printing Display alone does not help either. Proposal Handle the error in main: print the error and its cause chain to stderr, one cause per line, and exit with code 1. Do not change the exit codes here. Distinct exit codes stay in #4452. Acceptance iggy ping against a stopped server prints a readable message and its causes, with no Rust type names. A failing command still exits with code 1. Existing CLI integration tests that check error output are updated and pass.

Split from #4451. Problem The CLI reads credentials from IGGY_USERNAME and IGGY_PASSWORD (core/cli/src/credentials.rs:38-39, :148), but no variable holds a token. A CI job has to pass the token with -t, where the process list shows it, or write it to contexts.toml. Proposal Read IGGY_TOKEN in credentials.rs, next to the IGGY_USERNAME and IGGY_PASSWORD pair. Order: the flags win over IGGY_TOKEN, and IGGY_TOKEN wins over the username and password pair. Keep this in credentials.rs, not as a clap env attribute. In its conflict rules clap treats an environment value like a flag, so -u would fail while the variable is set. Mention IGGY_TOKEN, IGGY_USERNAME and IGGY_PASSWORD in the --help text of the credential flags. Acceptance With IGGY_TOKEN set to a valid PAT and no credential flags, iggy stream list succeeds. -u/-p or -t on the command line override IGGY_TOKEN. With IGGY_TOKEN and the username and password pair all set, the token is used. A test in core/integration/tests/cli/user/test

Split from #4447. Problem You cannot see consumer lag (the messages that a group did not consume yet). iggy consumer-group get shows members and partitions, but no offsets (core/cli/src/commands/binary_consumer_groups/get_consumer_group.rs). consumer-offset get shows one partition per call. Proposal Add a partitions table to consumer-group get, one row per partition of the topic: partition, member, current offset, stored offset and lag. Read each offset with get_consumer_offset and a Consumer of kind ConsumerGroup. A client does not need to be a member to read a group offset. The result is ConsumerOffsetInfo (core/common/src/types/consumer/consumer_offset_info.rs:26). The stored offset is the last consumed offset, so the lag is the current offset minus the stored offset. If no offset is stored, show - for the stored offset, and use the message count of the partition as the lag. The member column comes from the members list that the command already reads. Notes Over HTTP the group ki