-
Notifications
You must be signed in to change notification settings - Fork 179
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
refactor(app): Collect system USB information #5482
Conversation
Because the
|
Codecov Report
@@ Coverage Diff @@
## edge #5482 +/- ##
==========================================
+ Coverage 65.65% 66.54% +0.88%
==========================================
Files 1084 1095 +11
Lines 30918 31952 +1034
==========================================
+ Hits 20300 21262 +962
- Misses 10618 10690 +72
Continue to review full report at Codecov.
|
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.
Some inline comments
@@ -87,6 +87,8 @@ jobs: | |||
name: 'JS unit tests; build Protocol Designer, Labware Library, Components Library' | |||
# node version pulled from .nvmrc | |||
language: node_js | |||
before_install: | |||
- sudo apt-get install -y --no-install-recommends libudev-dev |
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.
this is only a build dep, right?
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.
Yeah, but hopefully it's unnecessary now that usb-detection
is publishing prebuilt binaries for the correct node versions. Still evaluating but will likely updaate the travis config once more
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.
Looks like there's some continuing native build shenanigans. For now, it appears we need both the prebuilt binaries and these build dependencies in place for everything to work. My hunch is that there's a problem with the Linux prebuilt binaries.
The usb-detection
author appears to be in the middle of a node-gyp
upgrade, so I'll take a look at removing these deps when that update is released. Keeping in place right now so we can have successful builds.
|
||
const addDriverVersion = (device: Device): Promise<UsbDevice> => { | ||
if (isWindows() && RE_REALTEK.test(device.manufacturer)) { | ||
return getWindowsDriverVersion(device).then(windowsDriverVersion => ({ |
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'll be ok if this gets called for two different devices right? Like if the user has a realtek USB wifi adapter or something?
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 don't see why the underlying PowerShell call would care, and the individual device states are separate in the application state, so the results of each individual call will go to the correct place
import type { Action, Dispatch } from '../types' | ||
import type { UsbDeviceMonitor, Device } from './usb-devices' | ||
|
||
const RE_REALTEK = /realtek/i |
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 would love to see this filtered on vendor ID rather than a string match
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 think you can even bake a VID into the usb-detector command string
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.
Avoiding locking ourselves to the VID was a conscious decision. IMO we don't have enough information to know that the VID is stable enough to filter on. I'd like to go wide right now and use the analytics info collected (including VID) to verify that we can narrow it down. I've def seen VID / PID shenanigans with counterfeit USB devices in China and I'm sure you've seen the same
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.
Yup fair enough
return result | ||
} | ||
|
||
export const isRealtekDevice = (device: UsbDevice) => { |
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 appear to check for this in a couple different places, could we check it only on the boundary to the usb detector so we can make this log whatever usb devices come through?
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.
This utility function is used to take the wide list of USB devices in state and narrow it down for updating the user's analytics and support profiles with the Realtek information if we see it. For similar reasons to going wide w.r.t. VID, I'd like to go wide on USB devices collection at the state level
If your concern is "this function should log when it sees a Realtek device", then that logging is already happening via MixPanel and Intercom
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'm a bit uncomfortable with wide logging of every USB device a user has plugged in to their system, but I guess we don't use it anywhere
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.
Yeah I'd really like to re-evaluate and narrow down once we do have some of that initial data. To be clear, only "realtek" devices get sent up to MixPanel and Intercom. Everything else just sits in state.
There are a few instances where having everything in state could prove useful that I can think of:
- It seems like (on the dongles I have) the USB device serial number matches the MAC address of the interface, so we may be able to match up the U2E interface (feat: Add system networking interface info collection to app #5397) with an actual device, "Realtek" or not
- Detecting if the device is plugged in via a hub
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.
Great stuff.
} | ||
} | ||
|
||
const decToHex = (number: number) => |
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.
Sooooo functional! ;)
case RobotSettings.FETCH_SETTINGS_SUCCESS: | ||
case RobotSettings.UPDATE_SETTING_SUCCESS: | ||
case Pipettes.FETCH_PIPETTES_SUCCESS: { | ||
const robot = getConnectedRobot(state) |
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.
Nit: This is a lot of code in a case statement. Perhaps it's justified to be it's own function?
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.
Yeah that's a good call. This was more or less copied over from the previous support profile implementation, it's doing too much, and it's got no unit tests. I'll add a TODO comment + ticket for now
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.
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.
🌽
- code looks sane
- redux work for init, add, and remove all perform as expected
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.
👍Worked on windows!
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.
Works as expected. Tests look good
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.
Works for me on Linux
overview
This PR closes #5358 by adding USB device information collection to the app. See ticket for acceptance criteria.
changelog
review requests
Functionality should be tested on all three OS's with the
enableSystemInfo
feature flag on. Simple test plan:state.systemInfo.usbDevices
state.systemInfo.usbDevices
windowsDriverVersion
field set to a string (null
means something went wrong)state.systemInfo.usbDevices
windowsDriverVersion
field set to a string (null
means something went wrong)state.systemInfo.usbDevices
risk assessment
Low, feature is currently behind the
enableSystemInfo
feature flag. Existing Intercom support profile was found to be buggy and un-tested, so I refactored some of it and covered it in tests