Avoid retaining failed TLS connections in sender - #47
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Failed TLS dials return a nil
*tls.Conn. Assigning that pointer tonet.Connleft the interface non-nil, so an expired certificate or other failure on every target IP could panic inRemoteAddrand the deferredClose.Extract the IP dial loop and return a connection only after a successful TLS handshake. Exhausting the IPs returns a nil interface, reaching the existing retry/backoff path. The timeout, IP order, certificate verification, TLS configuration, and protocol handling are unchanged.
Regression tests use real loopback TLS servers: a trusted but expired certificate yields no retained connection, and an unreachable first IP falls back to a usable connection with verified TLS 1.3 and
fmsg/1ALPN. The expired-certificate test reproduced the non-nil interface failure before the fix.Remove the README's "Immutable message finalization and upgrades" section.
Integration prerequisite: fmsg-docker #22 upgrades the harness builder images to Go 1.27, which the current components require. Merge that PR before this one. The matching
fix/sender-tls-connectionbranch in fmsg-docker points to its existing tested changes so this PR's integration check can run while the prerequisite awaits approval.Validation passed on Go 1.27.1:
go build ./...go vet ./...go test -race ./..., including the PostgreSQL integration tests against an isolated local instance.