Issue #136 moved all state related information in gtmrecv_poll_actions.c into a structure
variable "curr_conn_state". But there was another global variable "gtmrecv_send_cmp2uncmp"
which was set in gtmrecv_process.c and was the same as "curr_conn_state.send_cmp2uncmp"
which meant whenever "curr_conn_state.send_cmp2uncmp" got cleared (due to the memset
changed introduced in #136), "gtmrecv_send_cmp2uncmp" should have also been cleared.
Not doing so, meant it was still possible for a stale old connection related state
variable to be carried over to a new connection resulting in an assert failure in the
source server in rare cases (just like #136) in dbg or a connection loss and reconnect
sequence in pro (this did happen in one in-house test failure). This is now fixed
so both variables are kept in sync.
It was originally thought of avoiding the duplication and replacing all usages of
"gtmrecv_send_cmp2uncmp" with "curr_conn_state.send_cmp2uncmp" but it was not trivial
due to the need to move the "conn_state_t" type definition from gtmsource_poll_actions.c
into a header file so gtmrecv_process.c can also inherit that definition. And since this
is an edge case, and there was a risk of other subtle regressions, the trivial change
was adopted even though it is not as desirable.
Issue #136 moved all state related information in gtmrecv_poll_actions.c into a structure variable "curr_conn_state". But there was another global variable "gtmrecv_send_cmp2uncmp" which was set in gtmrecv_process.c and was the same as "curr_conn_state.send_cmp2uncmp" which meant whenever "curr_conn_state.send_cmp2uncmp" got cleared (due to the memset changed introduced in #136), "gtmrecv_send_cmp2uncmp" should have also been cleared. Not doing so, meant it was still possible for a stale old connection related state variable to be carried over to a new connection resulting in an assert failure in the source server in rare cases (just like #136) in dbg or a connection loss and reconnect sequence in pro (this did happen in one in-house test failure). This is now fixed so both variables are kept in sync.
It was originally thought of avoiding the duplication and replacing all usages of "gtmrecv_send_cmp2uncmp" with "curr_conn_state.send_cmp2uncmp" but it was not trivial due to the need to move the "conn_state_t" type definition from gtmsource_poll_actions.c into a header file so gtmrecv_process.c can also inherit that definition. And since this is an edge case, and there was a risk of other subtle regressions, the trivial change was adopted even though it is not as desirable.