feat(go): align TCP client logging with Rust SDK

[slash-init]

Which issue does this PR address?

Relates to #3460

Rationale

The Go SDK's TCP client has fewer diagnostic logs than the Rust SDK, making it harder to trace request/response flow, connection lifecycle events, authentication, TLS configuration issues, and leader redirection behavior.

What changed?

Added missing TCP client logs for requests, responses, connections, authentication, TLS errors, and leader redirection.
The logs were added to match the Rust SDK more closely and make debugging easier.

Local Execution

• Passed
• Pre-commit hooks ran

AI Usage

1. Claude Opus 4.6
2. Helped compare logs and review changes.
3. Verified by reviewing the changes and running local checks.
4. Yes.

[github-actions]

Thanks for the PR. It is labeled S-waiting-on-review and queued for review.

Slash commands (own line, regular comment) move it around the queue:

• /ready - back to S-waiting-on-review after addressing feedback
• /author - flip to S-waiting-on-author while you finish changes
• /request-review @user-or-team - request a reviewer

See CONTRIBUTING.md for details.

[codecov]

Codecov Report

❌ Patch coverage is 18.33333% with 49 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.70%. Comparing base (4a48008) to head (9b62aff).

Files with missing lines	Patch %	Lines
foreign/go/client/tcp/tcp_core.go	12.72%	46 Missing and 2 partials ⚠️
foreign/go/client/tcp/tcp_session_management.go	80.00%	1 Missing ⚠️

❌ Your patch check has failed because the patch coverage (18.33%) is below the target coverage (50.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3464      +/-   ##
============================================
+ Coverage     74.27%   74.70%   +0.43%     
  Complexity      937      937              
============================================
  Files          1259     1248      -11     
  Lines        125969   122579    -3390     
  Branches     101644    99003    -2641     
============================================
- Hits          93558    91576    -1982     
+ Misses        29396    28036    -1360     
+ Partials       3015     2967      -48     

Components	Coverage Δ
Rust Core	75.87% <ø> (+0.71%)	⬆️
Java SDK	58.57% <ø> (ø)
C# SDK	69.80% <ø> (-2.31%)	⬇️
Python SDK	88.88% <ø> (ø)
PHP SDK	83.57% <ø> (-0.72%)	⬇️
Node SDK	91.22% <ø> (ø)
Go SDK	40.14% <18.33%> (-0.23%)	⬇️

Files with missing lines	Coverage Δ
foreign/go/client/tcp/tcp_session_management.go	57.14% <80.00%> (+1.75%)	⬆️
foreign/go/client/tcp/tcp_core.go	51.04% <12.72%> (-6.20%)	⬇️

... and 87 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.

[chengxilo]

nit: Just a minor stype recommendation
For example:

    c.logger.Info("Retrying to connect to server...", "retry_count", n+1, "max_retries", attempts, "error", err)

can be changed to

c.logger.Info("Retrying to connect to server...",
  slog.Uint64("retry_count", uint64(n+1)),
  slog.Uint64("max_retries", uint64(attempts)), 
  slog.Any("error", err))

For detailed reason, check this reference:
https://www.dash0.com/guides/logging-in-go-with-slog#adding-contextual-attributes-to-your-logs

To be honest I think the previous approach may be more clear. But if we have a lot of KVs, we probably need this strong but ugly approach.

I don't know why Go doesn't provide function like slog.Uint() for convenience. 🤦‍♂️

[slash-init]

nit: Just a minor stype recommendation For example:

    c.logger.Info("Retrying to connect to server...", "retry_count", n+1, "max_retries", attempts, "error", err)

can be changed to

c.logger.Info("Retrying to connect to server...",
  slog.Uint64("retry_count", uint64(n+1)),
  slog.Uint64("max_retries", uint64(attempts)), 
  slog.Any("error", err))

For detailed reason, check this reference: https://www.dash0.com/guides/logging-in-go-with-slog#adding-contextual-attributes-to-your-logs

To be honest I think the previous approach may be more clear. But if we have a lot of KVs, we probably need this strong but ugly approach.

I don't know why Go doesn't provide function like slog.Uint() for convenience. 🤦‍♂️

Thanks. I went with slog attributes.

Also, one thing I noticed is that Rust's SDK has a connection state guard in the send_raw() function before attempting any network operations. The Go SDK doesn't have one in sendWireAndFetchResponse(). Unless I'm missing something, it looks like calling an operation before Connect() succeeds could eventually reach c.conn.Write(...) while c.conn is still nil and result in a panic rather than ErrNotConnected.
Do we need one here too?

[chengxilo]

nit: Just a minor stype recommendation For example:

    c.logger.Info("Retrying to connect to server...", "retry_count", n+1, "max_retries", attempts, "error", err)

can be changed to

c.logger.Info("Retrying to connect to server...",
  slog.Uint64("retry_count", uint64(n+1)),
  slog.Uint64("max_retries", uint64(attempts)), 
  slog.Any("error", err))

For detailed reason, check this reference: https://www.dash0.com/guides/logging-in-go-with-slog#adding-contextual-attributes-to-your-logs
To be honest I think the previous approach may be more clear. But if we have a lot of KVs, we probably need this strong but ugly approach.
I don't know why Go doesn't provide function like slog.Uint() for convenience. 🤦‍♂️

Thanks. I went with slog attributes.

Also, one thing I noticed is that Rust's SDK has a connection state guard in the send_raw() function before attempting any network operations. The Go SDK doesn't have one in sendWireAndFetchResponse(). Unless I'm missing something, it looks like calling an operation before Connect() succeeds could eventually reach c.conn.Write(...) while c.conn is still nil and result in a panic rather than ErrNotConnected. Do we need one here too?

Makes sense to me, just go ahead and add it : )

[slash-init]

Done adding the state guard.
I also added nil guards in disconnect() and shutdown() since those can be called while a connection attempt is still in progress. In that case, c.conn may not have been assigned yet, which could lead to a nil pointer dereference panic.

[chengxilo]

lgtm

[atharvalade]

lgtm only one nit: foreign/go/client/tcp/tcp_core.go line 409-410

Wouldn't it read better to log the error before invalidateConnLocked()? That way structured log output captures connection state at time-of-failure, not post-teardown. Minor thing though, both orderings work.

[slash-init]

@atharvalade Thanks for the feedback! You're right, I've made the change.