-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Service Arch
-
Fully Compatible
-
ALL
-
v7.0, v6.0
-
Service Arch 2022-12-26, Service Arch 2022-11-28, Service Arch 2022-12-12, Service Arch 2023-01-09, Service Arch 2023-01-23, Service Arch 2023-02-06, Service Arch 2023-06-12, Service Arch 2023-06-26, Service Arch 2023-07-10, Service Arch 2023-07-24, Service Arch 2023-08-07
-
(copied to CRM)
Background/Problem
As part of implementing TCP Fast Open support, we calculate a variable that indicates whether the user specified any TCP Fast Open server parameters.
We use this variable in some places to decide whether to emit logs about success/failure enabling TCP Fast Open. We also intend to use this to decide whether to fail from connection establishment.
However, we forget to check whether the given error code indicates success or failure – the consequence is that whenever a user specifies any TCP Fast Open parameter, whether to turn it on, turn it off, or change the queue size, we will always fail connection establishment.
In some cases, this can trigger a crash, as seen in the linked HELP ticket. In other cases, this just permanently stalls the server, because we never establish the listener thread that would accept connections.
Relatedly, we always enable TCP Fast Open, even if the user attempts to disable it via server parameter.
Solution
- Only return early from connection establishment if the error code is a failure.
- Add logic only to enable TCP Fast Open if either the user doesn't specify (implicit enablement) or if the user specifies to enable TCP Fast Open. Do not enable it if the user indicates not to enable TCP Fast Open.
- Add tests to ensure that the behavior has been fixed.