OneConnect, Cookie Persistence, and LB_FAILED event

Hi Hoolio. You and I expected the same thing, but that is not what's happening. The case number is C1050675. Here's the explanation I got:

I just went over this with ES for clarification

How one connect works is each request is inspected for load balancing in the event that an LB modification needs to be made.

Which is almost the same as how a normal connection functions.

In this situation a lb decision already happened and it didn't need to make a modification.

Thats why you would need to do a detach in the event a desion has already been made.

One connect or not, when a pool is selected, it gets tied to the connection.

once a pool member is tied to a connection it will remain tied to it until the connection times out, another pool is selected to be tied to that connection or it is detached from that connection.

The recommendation we got was to add this iRule block at the beginning of our iRule:

if { not ($uri starts_with "/app") } {
   If the loadbalanced server is not the vip detach 
  if {not ([IP::local_addr] equals [LB::server addr])}
    {LB::detach}
}

Our other idea was to add a pool statement at the beginning of the rule, referencing a pool which has no members to try and force "an LB modification".

And while these may be viable workarounds, it really doesn't address my fundamental questions which are

a) Is the behavior we are seeing intended, or a bug?

b) If it is intended behavior, where is the documentation describing this behavior because I sure haven't found it.