Mode naming bug that causes outputs to incorrectly deactivate

[anthonymckay]

Anyone know if there is a recommended good way to report bugs other than just a blind email to support?

I came across a bug I was able to reliably reproduce when setting up a new Mode and generic output yesterday.

I added a new alternate "Feeding" mode called "Feeding & Aminos" with a new generic output type that was set to be active in all modes except this new one. Whenever I would switch to regular "Feeding" mode, it was deactivating the output the was only set to deactivate in "Feeding & Aminos".

My guess is that the internal code is generating an internal identifier for the mode based on the mode's label name and the '&' character is an illegal character for this identifier string. As a result it's probably ending up as just "Feeding" and therefore causing that output to deactivate in both "Feeding" and "Feeding & Aminos". Renaming the mode to something else after initially creating it with "Feeding & Aminos" didn't resolve the issue. It's likely only updating the label, and not the identifier the was already created. I had to explicitly delete the mode, and create a new one with a different name like "Amino Feeding" to work around this issue.

You can reproduce this by creating a new mode call "Feeding & Test", and then create a new generic output with no inputs or dependencies that only has "Feeding & Test" unchecked. Then switch to your regular "Feeding" mode and see if that new output incorrectly deactivates.

This was on a collective with an XP8 and X3, both running firmware version 263.

 

[thom_smith]

support@coralvue.com is the best avenue where @Carlos will see it, triage and prioritize the fix. I saw the thread you started in the FB group and an interim--although less than desirable--workaround suggested by @Danny to rename the mode. Your observation has also been reported on a private thread elsewhere in this forum. My initial belief is the & is being treated as an operator by the underlying code and your particular case it would be a problem if you had modes named either Feeding or Aminos those outputs would be in an incorrect state when Feeding & Aminos is activated.

 

[anthonymckay]

support@coralvue.com is the best avenue where @Carlos will see it, triage and prioritize the fix. I saw the thread you started in the FB group and an interim--although less than desirable--workaround suggested by @Danny to rename the mode. Your observation has also been reported on a private thread elsewhere in this forum. My initial belief is the & is being treated as an operator by the underlying code and your particular case it would be a problem if you had modes named either Feeding or Aminos those outputs would be in an incorrect state when Feeding & Aminos is activated.

Thank you. Depending the language I would be surprised if this is treating the '&' character in the label string as an operator. 1. because languages typically don't interpret strings as code, and 2. most languages treat a single '&' as an bitwise operator, and not a logical AND. For the later either an explicit 'and' is used, or alternatively '&&' to mean logical AND. I think based on the behavior I've seen it's more likely that the label string is being used to generate the mode object's ID, and it's truncating the string from the '&' till the end (maybe with a bad regex? dunno). Either way, this is should a very simple thing to debug for the developers.

 

[thom_smith]

Thank you. Depending the language I would be surprised if this is treating the '&' character in the label string as an operator. 1. because languages typically don't interpret strings as code, and 2. most languages treat a single '&' as an bitwise operator, and not a logical AND. For the later either an explicit 'and' is used, or alternatively '&&' to mean logical AND. I think based on the behavior I've seen it's more likely that the label string is being used to generate the mode object's ID, and it's truncating the string from the '&' till the end (maybe with a bad regex? dunno). Either way, this is should a very simple thing to debug for the developers.

Yea now that you mention it, it is probably recognizing the & as a special charactor and truncating the string there. The truncated (...and likely stripped...) string is then matching multiple modes. In cases where you have different behaviors between these matched modes it is behaving incorrectly. It would be an interesting test and prove exactly if you created another mode call Aminos which acted properly under all conditions. As you have pointed out would likely occur. I don't have access to the underlying code nor even know the language it is in. Agree though it should be a relatively simple fix to probably just escape any special characters in the mode name. As I said before, @Danny brought it up elsewhere here in a private thread after your FB post so CoralVue is now aware of it and should triage and prioritize soon. If you want to track yourself, the best avenue would be support@coralvue.com.

 

[Carlos]

Thank you for catching this. We are going to fix this in the next update.