[terry-xiaoyu]

Summary

gc_after_handshake silently stopped collecting TLS processes on OTP 28. OTP 28 changed the sslsocket tuple from 3 to 8 elements; the TLS worker pids moved to the connection_handler and payload_sender fields, so the existing gc/1 clauses matched only OTP <= 27 sockets and fell through to a no-op.

Add a clause for the 8-element sslsocket shape and share pid de-duplication with the legacy 3-element shapes. This restores the OTP <= 27 behaviour on OTP 28. DTLS is covered by the same path (both fields hold the same pid there).

Only the TLS worker processes are collected. The per-connection tls_dyn_connection_sup is not: OTP hibernates static supervisors on its own (during init on OTP 24-27, after the default 1 s hibernate_after on OTP 28), so collecting it at handshake would only save memory for the first second on OTP 28, and never on older releases.

The option is extracted from ssl_options before ssl:handshake/2,3, so nothing here changes the OTP option contract.

Backport

The commit applies to the 5.17.x line and is needed there for 5.17.10.

Testing

New Common Test cases in esockd_transport_SUITE drive a real TLS/DTLS handshake and assert major-GC trace events on the expected TLS worker processes:

• option enabled: the connection handler and the sender are collected;
• option disabled: neither is collected;
• #proxy_socket{} recursion;
• DTLS: both worker fields are the same pid and the global dtls_connection_sup is not collected;
• OTP 28 listen sockets (undefined pids) are a no-op.

The cases fail on the unfixed source with missing_gc_major and pass with the change on OTP 28. The full transport suite and rebar3 xref pass.

[zmstone]

mind this change: emqx/otp#129

[terry-xiaoyu]

mind this change: emqx/otp#129

verified on the fork OTP that has it (OTP-28.4.1-11, the builder image pinned by dev-61). With a real server-side handshake through esockd, under both ssl.connection_tree_owner=supervisor and = caller, gc/1 collects the connection handler and the sender. #129 only changes who starts the connection tree and unlinks the caller; the receiver-supervisor link and the supervisor's initial call are unchanged, so nothing in gc/1 depends on it.