justinmclean opened a new issue, #4210: URL: https://github.com/apache/iggy/issues/4210
### Description Three connection string options have a different key on QUIC than on TCP and WebSocket. Unknown keys are errors, so using another transport's key name makes the connection string fail. | Option | TCP | QUIC | WebSocket | |---|---|---|---| | Reconnection attempts | `reconnection_retries` | `reconnection_max_retries` | `reconnection_retries` | | Reconnection cooldown | `reestablish_after` | `reconnection_reestablish_after` | `reestablish_after` | | Certificate validation | none | `validate_certificate` | `tls_validate_certificate` | The parsers are the `*_connection_string_options.rs` files under `core/common/src/types/configuration/`. ### Affected area / component Rust SDK, Configuration ### Proposed solution Use one key per option across all transports, and accept the old keys as deprecated aliases for a release. The client builders already use one name for each across all three transports: `with_reconnection_max_retries`, `with_reestablish_after`, and `with_tls_validate_certificate` on TCP and WebSocket. Matching those gives `reconnection_max_retries`, `reestablish_after` and `tls_validate_certificate`. ### Alternatives considered Rename without aliases in the next release. Existing connection strings would then fail until updated. ### Contribution - [ ] I'm willing to submit a pull request to implement this feature ### Good first issue - [ ] I think this could be a good first issue for a new contributor -- 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]
