Two issue, that might be the problem.
This text is out of the documentation. A RID might be rejected by a consumer or provider.
Whenever the connection manager receives a request with a 'rid' that it has already received, it SHOULD return an HTTP 200 (OK) response that includes the buffered copy of the original XML response to the client.
There is a possibility that a client might subvert polling frequency limits by deliberately sending requests for the same 'rid' multiple times, and so a connection manager implementation MAY choose to impose a limit to the frequency or number of requests for the same 'rid'. If the client exceeds this limit then the connection manager SHOULD terminate the HTTP session and return a 'policy-violation' terminal binding error to the client (see Terminal Binding Conditions).
The second posibility, it looks like a request got lost, and it was re-transmitted (rid 2130667326). Jabberwerx saw the old rid and acknowledged it with an "OK", which is exactly what it's supposed to do in this case, according to the XMPP specification.
But Finesse (or your custom application) looks like it doesn't know how to handle that "OK". It was expecting the next request in the sequence (2130667327..2130667328) and was confused by the "OK" ack that jabberwerx returned on the older rid
