Symptoms

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'

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 an 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.

NOTE: There is a FlxPublisherDeleteTrustedStorage function, but it does not delete the anchor.

Depending on how anchoring has been implemented, you could delete the file or data themselves. However, be aware that it is risky to have the anchor in an easily discoverable location.