device names not accepted as deviceId - breaks particle-cli about spark-server

[jlkalberer]

I think we'd need to modify this file to make that work.

Is this call just for device attributes or is deviceID_or_name used throughout the products code as well?

[lbt]

So ... I'm not so sure - the DeviceManager.js file often calls into spark-protocol pretty fast.
eg https://github.com/Brewskey/spark-server/blob/dev/src/managers/DeviceManager.js#L95
So there's no place from the api incoming to that call that touches the repository.

What I think should happen is that all the DeviceManager calls should change their signature to either deviceID or deviceID_or_name and those that take the name should check the repository to see if the ID exists, if not they should lookup the ID by name. (eg I think claim will probably only take deviceID)

I think that repository is the thing that should provide the name->ID function (which should be done in a permission-safe way)

[jlkalberer]

Ok, but just to clarify -- the only APIs that are currently broken are those that deal with device attributes?
If I make this change I'll want to cover all use-cases.

[lbt]

No. All apis - eg I can't do :
particle flash ajar-head tinker
? Which type of device? Photon
attempting to flash firmware to your device ajar-head
Flash device failed: Could not get device for ID

But that works using the full ID

[jlkalberer]

Got it... I'm thinking the easiest thing to do is to coerce the deviceID_or_name in the controllers into a deviceID. That seems a lot safer than making the change in device manager since I think everything expects the actual device ID throughout the code.

[lbt]

I think that would be a good place too 👍

[lbt]

Main concern for me was whether the controllers should be looking at the device repository and doing permissions
Maybe if the DeviceManager provided ID_or_name_to_ID mechanism that would take care of permissions too (ie only matching name->ID for devices the user owns) - that way the controllers don't need to dig into that stuff too much?

[jlkalberer]

So I only made sure that the tests passed for this but I don't have an environment to test... Please close the issue if this resolves things for you.

[lbt]

Thanks for the fast response but it doesn't work I'm afraid

So in line 123 https://github.com/Brewskey/spark-server/blob/dev/src/managers/DeviceManager.js#L123
you call getByID but that throws an error (line 112) rather than returning null :)

Also am I right that the approach is going to call getByID twice - with each call invoking a publishandlisten :/

Maybe it would be better to invert the logic and have deviceAttributeRepository.getByName which returns an ID or the value passed in if no ID matching that value is found.
That can take an ID and return the ID (as no name is found) or a name and return the ID (if found) or the name. If a name is returned that will raise a 40x error as today.
So there would always be a quick DB lookup and only a single publishAndListen

Just my thoughts ... hope that helps

[jlkalberer]

Ok, pull again. I originally had this implementation but forgot to switch back after I fixed the tests -- it's a lot cleaner.

[lbt]

This works pretty well. I only looked at simple vars and functions yet though :)

There's a problem calling functions introduced by the 290 fix though
The response before that commit was actually a full attribute list with an additional "result" value.
After that fix the result value is missing

[jlkalberer]

I tested function calls with the CLI as well as making a curl call. I am seeing the full result coming back from the server as expected. It looks just like this response but with some additional properties.

[lbt]

I don't get the same.

So this result shows that all the functions and variables are there (not sure if this is intended) and also the post gets a "return_value" but info does not:

david@ash:~$ # git reset --hard e8a3d
david@ash:~$ curl spark-std:8080/v1/devices/#####/do_lock -d arg="unlock" -d access_token=####
{"connected":true,"functions":["do_lock"],"id":"#####","last_app":null,"last_heard":"2019-05-21T00:41:47.380Z","last_ip_address":"::ffff:10.0.0.124","name":"zuul","platform_id":0,"product_firmware_version":2,"product_id":0,"return_value":1,"status":"normal","variables":{"door_open":"int32","lock":"int32"}}
david@ash:~$ curl spark-std:8080/v1/devices/######?access_token=########{"connected":true,"functions":["do_lock"],"id":"########","last_app":null,"last_heard":"2019-05-21T00:42:06.475Z","last_ip_address":"::ffff:10.0.0.124","name":"zuul","platform_id":0,"product_firmware_version":2,"product_id":0,"status":"normal","variables":{"door_open":"int32","lock":"int32"}}

At this commit the results are the same. There is no "return_value" from the POST

david@ash:~$ # git reset --hard 535de2
david@ash:~$ curl spark-std:8080/v1/devices/####/do_lock -d arg="unlock" -d access_token=########
{"connected":true,"functions":["do_lock"],"id":"#######","last_app":null,"last_heard":"2019-05-21T00:42:54.660Z","last_ip_address":"::ffff:10.0.0.124","name":"zuul","platform_id":0,"product_firmware_version":2,"product_id":0,"status":"normal","variables":{"door_open":"int32","lock":"int32"}}
david@ash:~$ curl spark-std:8080/v1/devices/#####?access_token=#######
{"connected":true,"functions":["do_lock"],"id":"######","last_app":null,"last_heard":"2019-05-21T00:43:13.158Z","last_ip_address":"::ffff:10.0.0.124","name":"zuul","platform_id":0,"product_firmware_version":2,"product_id":0,"status":"normal","variables":{"door_open":"int32","lock":"int32"}}

Hope this is all helpful

[jlkalberer]

There was also an update to spark-protocol between versions. After I pull, I always run yarn so it updates the dependencies to match whatever is in the lock file. I don't use npm anymore so if there is a lock file for that, it's not being updated.

I'm pretty sure this is what the issue is because before my fix, calling a device's function would always throw a null reference exception.

[lbt]

Thanks for that pointer - I'll do some research into yarn :)