CASSGO-45 ConnectAddress() was refactored #1858

tengu-alt · 2025-01-13T11:37:10Z

Fix for the #1370

ConnectAddress() was refactored and returns an error instead of panic.

joao-r-reis

Left some comments. The host selection / load balancing policies need some changes, we shouldn't assume the address is always valid on those implementations.

joao-r-reis · 2025-01-14T15:46:13Z

cassandra_test.go

-			if hi.host.ConnectAddress().String() == host {
+			connAddr, err := hi.host.ConnectAddress()
+			if err != nil {
+				t.Error(err)


maybe this should be t.Fatal so the behavior of this test is consistent after the change?

Agree, fixed

joao-r-reis · 2025-01-14T15:53:27Z

control.go

@@ -261,16 +261,21 @@ func (c *controlConn) connect(hosts []*HostInfo) error {
 	var conn *Conn
 	var err error
 	for _, host := range hosts {
+		connAddr, err := host.ConnectAddress()
+		if err != nil {
+			c.session.logger.Printf("gocql: %v\n", err)


Usually we add a message for this error before we add the actual error string so something like:
c.session.logger.Printf("gocql: unable to use host for control connection, skipping it: %v\n", err)

joao-r-reis · 2025-01-14T15:55:17Z

control.go

@@ -423,16 +432,21 @@ func (c *controlConn) attemptReconnectToAnyOfHosts(hosts []*HostInfo) (*Conn, er
 	var conn *Conn
 	var err error
 	for _, host := range hosts {
+		connAddr, err := host.ConnectAddress()
+		if err != nil {
+			c.session.logger.Printf("gocql: %v\n", err)


same as comment above

joao-r-reis · 2025-01-14T15:58:35Z

control_test.go

-			t.Errorf("expected ip %v got %v for addr %q", test.ip, host.ConnectAddress(), test.addr)
+		connAddr, err := host.ConnectAddress()
+		if err != nil {
+			t.Errorf("%d: %v", i, err)


t.Errorf("could not get connect address of host %q to compare with expected: %v", test.addr, err)

joao-r-reis · 2025-01-14T16:00:34Z

filters.go

@@ -72,10 +72,13 @@ func WhiteListHostFilter(hosts ...string) HostFilter {

 	m := make(map[string]bool, len(hostInfos))
 	for _, host := range hostInfos {
-		m[host.ConnectAddress().String()] = true
+		connAddr, _ := host.ConnectAddress()


if err != nil I don't think it should be whitelisted, it should just continue

joao-r-reis · 2025-01-14T16:21:27Z

policies.go

@@ -862,10 +870,11 @@ func (d *dcAwareRR) AddHost(host *HostInfo) {
 }

 func (d *dcAwareRR) RemoveHost(host *HostInfo) {
+	connAddr, _ := host.ConnectAddress()


just return if unable to get conn addr but also need to add a check for this in AddHost so hosts with invalid connect addresses are not added

joao-r-reis · 2025-01-14T16:22:28Z

policies.go

@@ -970,7 +979,8 @@ func (d *rackAwareRR) AddHost(host *HostInfo) {

 func (d *rackAwareRR) RemoveHost(host *HostInfo) {
 	dist := d.HostTier(host)
-	d.hosts[dist].remove(host.ConnectAddress())
+	connAddr, _ := host.ConnectAddress()
+	d.hosts[dist].remove(connAddr)


same as above, check in AddHost so we don't add hosts with invalid addresses and then we can just return here when unable to get connAddr

joao-r-reis · 2025-01-14T16:24:16Z

session.go

@@ -394,7 +394,8 @@ func (s *Session) reconnectDownedHosts(intv time.Duration) {
 			if gocqlDebug {
 				buf := bytes.NewBufferString("Session.ring:")
 				for _, h := range hosts {
-					buf.WriteString("[" + h.ConnectAddress().String() + ":" + h.State().String() + "]")
+					connAddr, _ := h.ConnectAddress()


we shouldn't really ignore these errors, it's better to handle them than assuming that connAddr is always valid, just continue if unable to get connAddr

joao-r-reis · 2025-01-14T16:24:44Z

session.go

@@ -847,11 +848,12 @@ func (qm *queryMetrics) hostMetrics(host *HostInfo) *hostMetrics {
 // hostMetricsLocked gets or creates host metrics for given host.
 // It must be called only while holding qm.l lock.
 func (qm *queryMetrics) hostMetricsLocked(host *HostInfo) *hostMetrics {
-	metrics, exists := qm.m[host.ConnectAddress().String()]
+	connAddr, _ := host.ConnectAddress()
+	metrics, exists := qm.m[connAddr.String()]


We definitely should not be creating metrics objects for hosts with invalid connect addresses since they won't be used anyway.

Agree, fixed

joao-r-reis · 2025-01-14T16:26:19Z

token.go

 		buf.WriteString(sep)
 		sep = ","
 		buf.WriteString("\n\t[")
 		buf.WriteString(strconv.Itoa(i))
 		buf.WriteString("]")
 		buf.WriteString(th.token.String())
 		buf.WriteString(":")
-		buf.WriteString(th.host.ConnectAddress().String())
+		buf.WriteString(connAddr.String())


Will this print an empty string if err != nil ? Printing empty string on the address part could be fine but we could also print nil instead

As I have checked, it will print a nil

joao-r-reis · 2025-01-14T16:28:24Z

Also can you create a JIRA for this?

tengu-alt · 2025-01-16T08:12:24Z

Also can you create a JIRA for this?

Of course, currently working on refactoring.

joao-r-reis · 2025-01-22T16:21:10Z

I just had a realization that we are probably going about this the wrong way. Instead of changing ConnectAddress() to return an error we should probably ensure that we never create Host objects with invalid addresses in the first place, I think that would result in a clearer API and less intrusive changes to users.

Sorry for not realizing this earlier, I know you already worked a bit on this approach but I really think we should change the approach here.

First step is to find all occurences of straight Host struct initialization and replace them with a newHostInfo(addr net.IP, port int) (*Host, error) so that the ip validation occurs here in this method instead of host.ConnectAddress(). The only place where it will require some more changes is in func (r *ringDescriber) getClusterPeerInfo(localHost *HostInfo) ([]*HostInfo, error) because here the object is created without an IP address since it will be set after reading the columns from system.peers. A possible approach is to move the logic from h.connectAddressLocked() to a function outside of the hostinfo type, use it to compute the connect address and then use the result to create the host info object afterwards. After this change, I think h.ConnectAddress() can always read the value from the h.connectAddress field. After this change, h.SetConnectAddress should be changed to return an error in case the provided address is invalid (this is only in case a user is using this function because the driver itself doesn't use it).

tengu-alt · 2025-01-24T08:25:32Z

Understood, I will work on it.

tengu-alt force-pushed the refactor-connect-address-method branch from 6f8773a to 8aae39b Compare January 14, 2025 08:25

joao-r-reis reviewed Jan 14, 2025

View reviewed changes

ConnectAddress() was refactored

c884b90

tengu-alt force-pushed the refactor-connect-address-method branch from 8aae39b to c884b90 Compare January 16, 2025 09:43

tengu-alt changed the title ~~ConnectAddress() was refactored~~ CASSGO-45 - ConnectAddress() was refactored Jan 16, 2025

tengu-alt changed the title ~~CASSGO-45 - ConnectAddress() was refactored~~ CASSGO-45 ConnectAddress() was refactored Jan 16, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CASSGO-45 ConnectAddress() was refactored #1858

CASSGO-45 ConnectAddress() was refactored #1858

tengu-alt commented Jan 13, 2025

joao-r-reis left a comment •

edited

Loading

joao-r-reis Jan 14, 2025

tengu-alt Jan 16, 2025

joao-r-reis Jan 14, 2025

tengu-alt Jan 16, 2025

joao-r-reis Jan 14, 2025

joao-r-reis Jan 14, 2025

joao-r-reis Jan 14, 2025

joao-r-reis Jan 14, 2025

joao-r-reis Jan 14, 2025

tengu-alt Jan 16, 2025

joao-r-reis Jan 14, 2025

joao-r-reis Jan 14, 2025

tengu-alt Jan 16, 2025

joao-r-reis Jan 14, 2025

tengu-alt Jan 16, 2025

joao-r-reis commented Jan 14, 2025

tengu-alt commented Jan 16, 2025

joao-r-reis commented Jan 22, 2025

tengu-alt commented Jan 24, 2025

CASSGO-45 ConnectAddress() was refactored #1858

Are you sure you want to change the base?

CASSGO-45 ConnectAddress() was refactored #1858

Conversation

tengu-alt commented Jan 13, 2025

joao-r-reis left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joao-r-reis commented Jan 14, 2025

tengu-alt commented Jan 16, 2025

joao-r-reis commented Jan 22, 2025

tengu-alt commented Jan 24, 2025

joao-r-reis left a comment •

edited

Loading