When processing a capability response from the back office, the following error is reported - FLXERR_RESPONSE_STALE - 'Response is out of order with previous responses'
When processing a capability response from the back office, the following error is reported - FLXERR_RESPONSE_STALE - 'Response is out of order with previous responses'
Summary
This KB article helps to resolve the issue - When processing a capability response from the back office, the following error is reported - FLXERR_RESPONSE_STALE - 'Response is out of order with previous responses'
Symptoms
When processing the capability response from the back office, the following error is reported: FLXERR_RESPONSE_STALE - Response is out of order with previous responses.
Example use case:
Capability Request 1 to FlexNet Operations contains a client trusted storage last-response timestamp of "never".
Capability Response 1 from FlexNet Operations contains a timestamp of (say) "Wednesday at 4:00".
Capability Request 2 to a local server contains a last-response timestamp of "never".
Capability Response 2 from the local server contains a timestamp of (say) "Wednesday at 4:30".
Capability Response 2 is processed, and client's trusted storage last-response timestamp is updated to "Wednesday at 4:30".
Capability Response 1 can't be processed because its timestamp is earlier than what's already there, and so it returns the FLXERR_RESPONSE_STALE error.
Cause
This behavior is intentional to prevent an adversarial user from saving a response, processing it to use its licenses, returning the licenses, and then re-processing the old response to get illicit licenses.
Resolution
There is the option to use a buffer license (what FlexNet Operations calls a pre-built license) from FlexNet Operations, if the device ID is known ahead of time. This would sidestep the issue, reported above, with timestamps..
Otherwise, there isn't a built-in "purge the anchor" operation. (There's a FlxPublisherDeleteTrustedStorage function, but it does not delete the anchor.) Depending on how anchoring has been implemented, you could delete the file/data themselves, but be aware it's dangerous to have the anchor in an easy-to-find location.
