fleet/changes/31385-dep-sync-url-incorrect
Jordan Montgomery f1662e1da6
Mark dep assignments as failed on certain server errors (#31523)
Putting this up for comments

On certain errors(like a network error, perhaps even Apple ratelimiting)
we previously would drop assignments during the DEP sync and leave the
host_dep_assignments row null and the assignment unset on the Apple
side. Because of how the sync works it is entirely possible when this
happens that we would happily go along, update the cursor and never
return to resync these devices unless and until the admin did something
that forced a resync like changing something about the cloud config
profile.

Now any devices that for any reason don't get returned by the response
get marked as failed so that our logic for retrying and processing
cooldowns picks them up for later retry.

Explanation here as far as what I think is going wrong:
https://github.com/fleetdm/fleet/issues/31385#issuecomment-3145117080

# Checklist for submitter

If some of the following don't apply, delete the relevant line.

- [ ] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
See [Changes
files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files)
for more information.

- [ ] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [ ] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes

## Testing

- [x] Added/updated automated tests
- [x] Where appropriate, [automated tests simulate multiple hosts and
test for host
isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing)
(updates to one hosts's records do not affect another)

- [x] QA'd all new/changed functionality manually
2025-08-06 13:15:43 -04:00

1 line
152 B
Text

Fixed an issue during the DEP sync where errors such as 404 from the DEP API could result in devices never being assigned a cloud configuration profile