Patch policy installs run against a stale cached version of Fleet-maintained apps

[spalmesano0]

• customer-sanchez: Slack thread.

Fleet versions

• Discovered: 4.89.1
• Reproduced:

Web browser and operating system: N/A

---

💥  Actual behavior

When an FMA install runs via a patch policy, the install script sometimes runs against a stale, previously-cached installer package instead of the version currently shown as the target in Fleet (self-service, activity feed, and patch policy).

Observed with multiple FMAs:

• Tailscale: Self-service/activity showed Tailscale-1.98.9-macos.pkg, but the install script log referenced an older cached package (Tailscale-1.98.5-macos.pkg) across three separate install attempts.
• Fleet Desktop: Activity reported fleet_desktop-v1.3.2.pkg installed, but the install script log referenced fleet_desktop-v1.3.1.pkg.
• Okta Verify: Policy/UI showed target version 9.65.2, but the install script log showed it installing 9.63.0. Pinning the FMA to 9.63.0 and re-running resolved it for that host.

Note: because of #49475, these mismatched installs are also misreported as "installed" successfully, which hides the failure.

🛠️ Expected behavior

The version the install script actually installs should match the version Fleet displays as the current target (self-service, activity feed, patch policy).

🧑‍💻  Steps to reproduce

These steps:

• Have been confirmed to consistently lead to reproduction in multiple Fleet instances.
• Describe the workflow that led to the error, but have not yet been reproduced in multiple Fleet instances.

1. Set up an FMA in the UI, with an older version already installed on the host.
2. Set up a patch policy for that app via GitOps, scoped to the fleet containing the host.
3. Let Fleet promote the FMA to a newer version, then trigger the install (self-service or patch policy automation).

🕯️ More info (optional)

• Found while investigating Failed software installs are reported as successful #49475.
• sanchez' setup: software managed via UI, patch policies defined in GitOps as a single YAML file scoped per fleet.

[spalmesano0]

@georgekarrv Requesting a P1 on this one as well, as patch policies are failing to pick up the correct version. It may be more widespread, but others may not be reporting it when it's combined with #49475.