Request data caching can lead to old updates in combination with the authentication

[pLeminoq]

This bug occurs in the device manager unit tests since authenticated remotes will trigger an authenticated request after receiving data on the listener where only data visible for all users is published.

This is because applying an action leads to two updates. For the first update the requested state is set and for the second update the current state is set. These updates follow each other very quickly. The remote triggers an authenticated request after receiving the first update. This also happens very fast so that the answer from the server is the same as the update received. But the request is not yet finished because it also includes some more steps on the remote side like decrypting the answer. While this is happening the second update is received. This also triggers a request but not really since the first one is still running and cached. Therefore the remote never receives the latest data.

I think there exist two solutions:

• The request should exists in a non-cached variant or the remote creates a task which waits until the last request is complete before triggering a new one (at least the second proposal is easy to implement but it is not really efficient)
• The time a request is cached has to be reduced so that it directly ends after the server answers the request (I think this is harder to implement and I don't know if this can reduce the time so much the the error can never happen)

[pLeminoq]

The first version has been implemented on the transaction id feature branch but it still has to be discussed if this version should be used.