-
Notifications
You must be signed in to change notification settings - Fork 750
DeviceLocation command handling and DB support #37668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DeviceLocation command handling and DB support #37668
Conversation
|
Note: integration testing will come after implementing the next backend subtask for this story. |
| if ok { | ||
| for _, f := range handlers { | ||
| if err := f(ctx, result); err != nil { | ||
| // TODO: should we run as many as we can? if so we have to collect into a multierror |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can address this in a subsequent PR, since this is the existing behavior
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guessing we'll need this for automatic VPP updates anyway? /cc @lucasmrod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gonna merge on top of this and @lucasmrod can stack on top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guessing we'll need this for automatic VPP updates anyway?
Do we? Will there be any commands that will be processed by more than one handler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on where you're hooking in on MDM-driven software inventory, I suppose.
Guessing you already built that out though so maybe we're good to go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on where you're hooking in on MDM-driven software inventory, I suppose.
Guessing you already built that out though so maybe we're good to go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on where you're hooking in on MDM-driven software inventory, I suppose.
Guessing you already built that out though so maybe we're good to go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on where you're hooking in on MDM-driven software inventory, I suppose.
Guessing you already built that out though so maybe we're good to go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we? Will there be any commands that will be processed by more than one handler?
I think yes, eventually. The goal with the handlers was to make a pattern for handling MDM command results for independent operations. That way we don't end up with 1 mega-function per MDM command result type that tries to contain all possible Fleet logic for that type.
server/datastore/mysql/migrations/tables/20251222174712_AddHostLocationSupport.go
Outdated
Show resolved
Hide resolved
server/datastore/mysql/migrations/tables/20251222174712_AddHostLocationSupport.go
Outdated
Show resolved
Hide resolved
server/datastore/mysql/migrations/tables/20251222174712_AddHostLocationSupport_test.go
Outdated
Show resolved
Hide resolved
| ctx := context.Background() | ||
| iOSHost := newTestHostWithPlatform(t, ds, "iphone_"+t.Name(), string(fleet.IOSPlatform), nil) | ||
|
|
||
| err := ds.InsertHostLocationData(ctx, iOSHost.ID, 42.42, -42.42) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on rolling this up into the HostLocation struct, including adding host ID in? At which point you can just check equality on the round trip (which for this low of precision should work despite dealing with a float to decimal conversion).
Also, since we aren't doing math, maybe specifying the struct fields for lat/long as strings is a better idea here, so we don't lose anything going from string-formatted in the plist to floats and then back to fixed-point in the database.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on rolling this up into the HostLocation struct, including adding host ID in? At which point you can just check equality on the round trip (which for this low of precision should work despite dealing with a float to decimal conversion).
sgtm 👍
Also, since we aren't doing math, maybe specifying the struct fields for lat/long as strings is a better idea here, so we don't lose anything going from string-formatted in the plist to floats and then back to fixed-point in the database.
I have a slight preference for leaving it as floats, but not huge. Seems like floats might be something we need in future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gonna continue pushing on the floats thing because we can maintain precision from the Apple result of we don't do that.
If we need to do math on these later, it'll probably be in the database anyway, which is (correctly) defined as fixed-point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrm, seems like I can't unmarshal the plist fields into a string.
I get
err="build device location command result: device location command result: xml unmarshal: plist: cannot unmarshal $VERY_LONG_DECIMAL_HERE into Go value of type string"
Does it make sense to unmarshal into float64, then turn those into strings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, doesn't make sense after we hit floating point. Can leave this as is then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, doesn't make sense after we hit floating point. Can leave this as is then.
| if ok { | ||
| for _, f := range handlers { | ||
| if err := f(ctx, result); err != nil { | ||
| // TODO: should we run as many as we can? if so we have to collect into a multierror |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guessing we'll need this for automatic VPP updates anyway? /cc @lucasmrod
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 33509-feature-branch #37668 +/- ##
========================================================
+ Coverage 65.81% 65.84% +0.03%
========================================================
Files 2367 2367
Lines 187677 187587 -90
Branches 7907 7980 +73
========================================================
+ Hits 123519 123525 +6
+ Misses 52857 52758 -99
- Partials 11301 11304 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Looks like the failing test is unrelated FYI |
iansltx
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, found a few more things. Setting this to draft in the mean time.
server/service/apple_mdm.go
Outdated
| host, err := svc.ds.HostByIdentifier(r.Context, cmdResult.Identifier()) | ||
| if err != nil { | ||
| return nil, ctxerr.Wrap(r.Context, err, "DisableLostMode: get host by identifier") | ||
| } | ||
|
|
||
| if err := svc.ds.DeleteHostLocationData(r.Context, host.ID); err != nil { | ||
| return nil, ctxerr.Wrap(r.Context, err, "DisableLostMode: delete host location data") | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking we want to put this, plus the device location command on lost mode entry, inside the status gate rather than before it? Otherwise we could be clearing location on a pending lost mode request right?
| } | ||
|
|
||
| case fleet.DeviceLocationCmdName: | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to check for command status here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iansltx I added a check for command success status (Acknowledged). Any error handling is a product decision (e.g. should we retry?) and can be added in followup PRs relatively easily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jahzielv In case of an error, we have this state in the Location modal:

We will soon surface MDM commands in the activity, allowing users to track if a location command has failed.
| if err != nil { | ||
| return ctxerr.Wrap(ctx, err, "device location command result: insert host location data") | ||
| } | ||
|
|
||
| return nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can just return the wrap here, right?
…location-mdm-command
iansltx
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See Marko's comment, plus the question I asked on the FE PR, but this looks reasonable. Can discuss those two items further in standup.
|
Actually @jahzielv you'll need to bump the migration here. Will re-approve after. |
Related issue: Resolves #37265
Checklist for submitter
If some of the following don't apply, delete the relevant line.
SELECT *is avoided, SQL injection is prevented (using placeholders for values in statements)Testing
Added/updated automated tests
Where appropriate, automated tests simulate multiple hosts and test for host isolation (updates to one hosts's records do not affect another)
QA'd all new/changed functionality manually