Granola Windows FMA repeatedly breaks GitOps runs as vendor rotates installer URLs

[kc9wwh]

Fleet versions

• Discovered: v4.83.0
• Reproduced: v4.83.2

Web browser and operating system: N/A

---

💥 Actual behavior

fleetctl gitops fails with a fatal validation error when the Granola Windows FMA (slug: granola/windows) is present in software config. The dry-run aborts even when the user's change has nothing to do with Granola or Windows.

Representative error:

Error: applying software installers for fleet "💻 Windows": validation failed: software.url Couldn't edit software. URL ("https://api.granola.ai/v1/check-for-update/Granola-7.162.2-win-x64.exe") received response status code 403.
Error: Process completed with exit code 1.

Root cause appears to be vendor-side URL invalidation cadence: Granola ships new Windows versions every few days and invalidates the previous version's installer URL (returns 403) as soon as the new release goes out. Fleet refreshes the FMA catalog 6 times a day, but the Granola invalidation window is short enough that a customer's GitOps run can still land on a URL that's already dead between catalog refreshes. The run then fails fatally rather than warning.

Observed on three separate occasions over the span of three weeks, each tied to a new Granola release. Independently reproduced by a Fleet engineer.

🛠️ Expected behavior

The customer's expectation is simple: GitOps should just work. Fleet should grab the latest valid installer URL at run time without failing because the vendor rotated a version-specific URL.

Possible directions:

• Stable "latest" URL fallback: Point the Granola FMA entry at a vendor-provided, version-agnostic URL (e.g., https://api.granola.ai/v1/download-latest-windows) that always resolves to the current installer. Fleet resolves the actual version at run time rather than validating against a pinned URL that may already be dead. Could be generalized to any FMA whose vendor offers a stable "latest" endpoint.
• Resolve-at-run for FMAs: Refetch the FMA installer URL from the catalog at GitOps execution time rather than validating against a snapshot that may have gone stale between catalog refreshes.
• Skip re-validation when unchanged: If the FMA slug hasn't changed since the last successful run, skip the URL validation step for that entry.

PD to specify final behavior.

🧑‍💻 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. Add slug: granola/windows to a Windows team's software.packages in a GitOps repo.
2. Successfully run fleetctl gitops once to confirm the baseline works.
3. Wait until the next Granola release ships (typically within a few days).
4. Make any unrelated change in the GitOps config and run fleetctl gitops (or fleetctl gitops --dry-run) again.
5. Observe: the run fails with software.url ... received response status code 403 pointing at the previous Granola Windows installer URL.

🕯️ More info (optional)

• Workaround: Comment out the granola/windows slug, re-run GitOps to unblock, then add it back once Fleet's next FMA catalog refresh has picked up the latest valid URL. Not sustainable given the recurrence rate.
• Cross-issue context: Related FMA version staleness behavior was filed as Granola FMA entry displays older version than Fleet reports as latest #44062. This issue is distinct — it's about GitOps fatally failing rather than displaying a stale version.
• Vendor behavior: Granola appears to invalidate old version URLs immediately on release rather than preserving them or returning a stable redirect. The customer has reached out to Granola directly and received a response acknowledging the issue; no commitment on URL stability yet.
• Business impact: Frequent enough that the team has discussed internally whether Granola is viable as an FMA at all in its current form.

[noahtalerman]

FYI @allenhouchins I moved this FMA bug over to :help-solutions-consulting.

[allenhouchins]

I'll keep researching but I'm not sure there is much we can do to resolve this at this time. The vendor has acknowledged the behavior which is not common with other vendors. We are already checking for updates at least 6 times a day. We updated Granola twice just yesterday alone. This may be a case where Granola is not a good candidate for FMA or the customer may want to opt for using the version pinning feature or managing the policy versions manually (or automated through scripting) and running a command like winget install Granola.Granola to always install the latest version.

I did discover this url https://notes.granola.ai/download but it always downloads the version of the app for the platform you are hitting that URL from, so that won't work in CI/CD, and it doesn't seem to support any parameters.

[bradleyjkemp]

Hey, happy to help out here from the Granola side

Sounds like as long as we kept the link for the previous version alive that would unblock this?

So a timeline like:

1. FMA update picks up Granola version N
2. We ship a new version of Granola, N+1 (currently that invalidates the version N link)
3. Fleet keeps working because the version N link is still active
4. FMA update picks up Granola version N+1
5. at some point later the version N link is deactivated, but that's fine because you're not relying on it any more

[kc9wwh]

Hey, happy to help out here from the Granola side

Sounds like as long as we kept the link for the previous version alive that would unblock this?

So a timeline like:

1. FMA update picks up Granola version N
2. We ship a new version of Granola, N+1 (currently that invalidates the version N link)
3. Fleet keeps working because the version N link is still active
4. FMA update picks up Granola version N+1
5. at some point later the version N link is deactivated, but that's fine because you're not relying on it any more

@allenhouchins?

[aanklewicz]

Hey @bradleyjkemp, thanks for chiming in from the Granola side. As a Fleet & Granola customer facing this, it's really nice to see the response here. You folks have a great product! If that kind of workflow could work, that would be very much appreciated. Even keeping the versions alive for a short while should resolve this issue, but I'll let Allen and the Fleet crew chime in.