Windows Fleet-maintained apps: After a Fleet-maintained app is added to a team it shouldn't be available to add again

[RachelElysia]

Fleet version: >= 4.77

💥  Actual behavior

• Added an FMA app to my instance (both local on main and confirmed on dogfood)
• FMA add software table is not showing software_title_id: for the app already added
• Causing the UI to show that it hasn't been added already even though it has

Screen.Recording.2026-01-02.at.11.00.50.AM.mov

🛠️ To fix

API should return software_title_id if it exists already.

🧑‍💻  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. Go to dogfood
2. Add a FMA app that has an upgrade code specified in the manifest (I did 7-zip and 8x8)
3. See that it has been added
4. Go to Add the FMA app again
5. Notice the UI allows you to add it again even though it's not available

🕯️ More info

This occurs because we check for "is this added already" byunique_identifier, allowing us to correctly mark macOS apps as "already added" even if the app name differs from the one we have in the manifest (by matching bundle ID). For Windows pre-upgrade-code we just had name as the unique identifier, so if the names matched we would report the installer as already added.

With >= 4.77 behavior overriding unique_identifier with upgrade_code for software titles where upgrade code exists, we now no longer have a match between the FMAs table (which is a local cache of the apps.json part of FMA manifests) and the software titles table, causing false negatives for any app that has an MSI.

Potential solutions each have their tradeoffs:

Match on name for Windows apps instead of unique_identifier

Rough estimate: 3-5pt

This is the quickest fix, as it requires no changes to FMA manifests or the database. Caveat here is that we won't match properly for cases where software has e.g. a version-locked name in the title (which is why we added upgrade codes in the first place). The software will still fail to upload, but if we get into this situation there's no way for the user to get out of it because inventory will keep the software title occupied and there's currently no way to change a software title's name on Windows (though we could extend this contributor endpoint to allow it).

Add upgrade code to apps.json, persist to the fleet_maintained_apps table

Rough estimate: 8-13pt

We would need to revise FMA ingestion to add a new field, plus create a database migration to add the new field to the fleet_maintained_apps table. Keeping FMA manifests as-is would require the hourly cron to download every WIndows based FMA to check upgrade code on the output manifest itself, slowing things down and potentially running into rate limit issues. We also don't want to change the existing unique identifier field at the top level at this point because that would break at least < 4.77 installs in the same way we're seeing here.

There's more investigation needed for this soltuion to ensure putting upgrade codes at the top level doesn't break anything else.

[iansltx]

Going to diagnose this to figure out if it's released.