I'll have to investigate this to find out if it's true, though I'm not sure it's totally appropriate to address if it is true.

Sticky sessions are not generally recommended and the reason why is that requests from one client are always directed to the same server, making that client dependent on that server. If you are using Service Discovery and the server drops from the pool, any clients that were sticky to that server will experience a loss of session and have other potential side effects. It doesn't seem like SD + Sticky Sessions would mix very well, especially in an environment where servers change frequently.

That being said, we do offer both, so we probably should implement a fix at some point if it doesn't already work.

It's true that sticky sessions are generally not favorable. But in some cases the underlying technology needs it. (Sadly)

If I understand your documentation correctly it's not supported. I might be mistaken though and if i am that would be great.

The reason why I would like sticky sessions is that we plan to use SignalR.
SignalR requires sticky sessions, so that the initial negotiations with the server reaches the same server every time.

I have looked into the ServiceFabric implementation and it looks like you're using the ServiceFabric reverse proxy for the load distribution?
If that's the case then Ocelot will not be able to support sticky sessions through ServiceFabric with the current implementation since the SF ReverseProxy doesn't support it.

There is an endpoint in ServiceFabric for retrieving information about each service that's running on the system (Service Discovery Provider) but it doesn't look like you're using it?