For long-lived policies like our policy-elastic-agent-on-cloud policy, we accrue many revisions over time, which results in confusing results and noise when debugging and working with support.

For example, when attempting to grab the current policy data during a support case, we recently ran this query and received 51 results.

GET .fleet-policies/_search?q=policy-elastic-agent-on-cloud

This makes it difficult to sort through the noise and determine the currently deployed revision of the policy for debugging purposes.

The way Fleet Server handles this in code is to sort the policy results in descending order of revision_idx and only grab the most recent revision:

https://github.com/elastic/fleet-server/blob/01349f51cedc19a3aac953d8564b27f81bb9dd35/internal/pkg/dl/policies.go#L23-L34

We could potentially imitate this behavior in the various queries we use for support purposes (potentially adds difficulty and verbosity), but there is likely also a justification for periodically truncating the list of revisions once it gets above some maximum size.

Fleet UI is responsible for writing to this index, while Fleet Server only reads from it. Therefore, Fleet UI should be responsible for its cleanup as the "writer" process here.

Fleet UI generates a document in .fleet-policies for each Agent Policy during setup here: