HAProxy stick table fails? - wcf

Question

I have a HAProxy balancing load on tcp-connections. For some reason, it seems that the stick-table fails once in a while. Here are few rows from my log where we can see that there has been an connection to both backends from single ip. Connections are made at the exact same timestamp, could it be that the stick table is not thread safe?
Expire time is only 10s for a reason, tcp connections in our software are quite sticky so we need short expire time for possible server maintenance procedures.
Any idea how this is possible? Why two simultaneous connections are routed to different backends? Our software cannot handle this situation, WCF is used for the communication.
Apr 11 14:06:07 accuna haproxy[22129]: xx.xx.133.145:12872 [11/Apr/2017:14:05:21.608] https_frontend https_backend/srv1
Apr 11 14:06:07 accuna haproxy[22129]: xx.xx.133.145:12872 [11/Apr/2017:14:05:21.608] https_frontend https_backend/srv1
Apr 11 14:06:07 accuna haproxy[22129]: xx.xx.133.145:3342 [11/Apr/2017:14:05:21.608] https_frontend https_backend/srv2
Apr 11 14:06:07 accuna haproxy[22129]: xx.xx.133.145:3342 [11/Apr/2017:14:05:21.608] https_frontend https_backend/srv2
Apr 11 14:06:07 accuna haproxy[22129]: xx.xx.133.145:22543 [11/Apr/2017:14:05:34.994] https_frontend https_backend/srv2
Apr 11 14:06:07 accuna haproxy[22129]: xx.xx.133.145:22543 [11/Apr/2017:14:05:34.994] https_frontend https_backend/srv2
Apr 11 14:06:07 accuna haproxy[22129]: xx.xx.133.145:26566 [11/Apr/2017:14:05:34.995] https_frontend https_backend/srv2
Apr 11 14:06:07 accuna haproxy[22129]: xx.xx.133.145:26566 [11/Apr/2017:14:05:34.995] https_frontend https_backend/srv2
HAproxy settings:
backend https_backend
mode tcp
option tcplog
balance leastconn
stick-table type ip size 200k expire 10s store conn_cur
tcp-request content track-sc0 src
stick on src
server srv1 10.1.4.210:443 check
server srv2 10.1.5.38:443 check

Answer 1

Since I met the same problem five years later, maybe it's not stressed enough in the docs. Turned out, my stick on rule
stick on req.payload(0,0),mqtt_field_value(connect,username) table mqtt_usernames
was checked too fast, before the content has arrived. I adjusted it with an inspect delay in my frontend config:
tcp-request inspect-delay 10s
acl content_present req_len gt 0
tcp-request content accept if content_present
and hopefully it's correct. At least, it passes my tests.