balena-cli: resin device rm returns an error if UUID is purely composed of numbers
when the short uuid is purely composed of numbers (Example: 585644) - resin device rm fails with the following error message.
ResinDeviceNotFound: Device not found: 585644
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 16 (11 by maintainers)
Commits related to this issue
- Fix uuid params being parsed a numbers Connects-To: #489 Change-Type: patch — committed to balena-io/balena-cli by thgreasi 6 years ago
- Fix uuid params being parsed a numbers Connects-To: #489 Change-Type: patch — committed to balena-io/balena-cli by thgreasi 6 years ago
- Fix uuid params being parsed a numbers Connects-To: #489 Change-Type: patch — committed to balena-io/balena-cli by thgreasi 6 years ago
- Fix uuid params being parsed a numbers Connects-To: #489 Change-Type: patch — committed to balena-io/balena-cli by thgreasi 6 years ago
- Fix uuid params being parsed a numbers Connects-To: #489 Change-Type: patch — committed to balena-io/balena-cli by thgreasi 6 years ago
- Fix uuid params being parsed a numbers Connects-To: #489 Change-Type: patch — committed to balena-io/balena-cli by thgreasi 6 years ago
Ah, gotcha. I think that’s ok - doing some quick maths, I think you’re 10x more likely to get struck by lightning this year than for any given 32 char UUID you generate to be all numbers. If we generate 10,000 a year, there’s still a 99.7% chance that none of them are completely numeric. I think handling that case can wait until Capitano gets a big refresh. By the sounds of it, it’d definitely need work in Capitano anyway.
I’ll close this for now, and we’ll fix it more thoroughly in https://github.com/resin-io/capitano/issues/60
We could do something like that, but it wouldn’t help existing devices, and it shouldn’t be necessary - the cli should know the type of any given parameter, so we just need to stop the parsing code from being too clever for it’s own good.