[Bug Report] large negative numbers in hub variable

Got my hubitat today, have to report a bug (sigh).

Observed behaviour

Creating a hub variable, name "intMan", type "Number", value "-212032831981301830138913089"

The field with the initial value disappears - jumping out and back into the settings option doesn't bring back the value field. Changing the type to "Decimal" resulted in the value being set (to the value shown) and inserted into the symbol table.

Expected behaviour

The value field should not disappear, some form of error message should be given, or (at worst) the incorrect value should be deleted. Perhaps it should be validating after each keystroke, and prevent you from entering in invalid values.

1 Like

And your point is what, exactly? Just busting edge cases?

When I put that value in an existing number variable it returns null, so that no doubt throws off the UI for creating a new variable, and in an existing decimal it gives this:

Screenshot 2022-12-08 at 3.35.19 PM

But, seriously, what's the point?

What is my point?

I thought you would be interested in unexpected behaviour of your software.

There are a number of questions I had...

Once the value is there how do I get rid of it?
The delete option is no longer there.
Going away from/returning to this page doesn't change it.
If I change it to a DateTime type it accepts it, but with bad DateTime as the value.
Only then do I get the option to delete the row.

Where does the fault get stopped? Does this interface allow for this strange value to be stored within itself? If the value can get in there will it affect other parts of the system?
Presumably groovy deals with it (perhaps it does, perhaps it doesn't - I don't know).
But can the rest of the logic of the system accept an anomalous value like this?

Perhaps people aren't going to do this because in the end it is their system, but could this be accidentally typed in? What if they copy/pasted a large value by accident, and they look at the screen and see the value field has disappeared?

If there is a path for invalid values to be entered could this be exploited by third party code? I don't know if you've followed the path of values and done boundary analysis of your code, but I thought I'd give you a heads up on at least one of the bugs I found.

I recently tried out GarageSale (on my mac) which has been around since at least 2009 and found a bug - they sorted numbers alphabetically, so shoe size measurements would end up as 1, 1.5, 10, 10.5, 11, 11.5, 2, 2.5. How was this overlooked for so long? Did no one say anything? Did they not realise?
I commented about this on their board; they worked on it, gave me access to the beta to test and it was fixed.

I've also worked adjacent to a compiler developer (I ran training sessions to companies using this particular language) and their attitude was that -anything- that was wrong should be reported, including incorrect comments in the compiler so I tend to take that attitude with me.

When I was developing software I was always happy to hear about -any- bug. When I was working as a software tester I found lots of bugs - they would be accepted and decisions made about the priority of fixing them (one had a leap year bug in it - when it was 29th Feb the program would return 1/Jan/1970 - I'm sure you know what was happening there), but I never had people asking "why are you telling me this?".

What sort of errors do you want to know about? Bad links? Documentation? Incorrect behaviour?
I couldn't find a dedicated channel to report bugs on (is this the correct forum for it?), or Hubitat's bug reporting policy.

BTW - another bug (I found this yesterday, a couple of hours after getting my hubitat)

When you are setting a basic rule with "Time of day" > "A certain time ...", have AM/PM set to PM and you click down on the minutes then click "Update", it always switches it back to AM.

Another issue.

Should the auto generated name for a Basic Rule be updated when the rules are changed?

The name shown on the "Apps" page reflects this name, but not the name exposed when you select "Change the Basic Rule Name?" - it seems to be set once, and no more, no matter how many edits are made to the rule.

What release are you on and what browser?

This is correct. You can change it, but it doesn't try to keep up.

As for the large negative number "bug", can't say this rises to something we'd spend our time on, as there are plenty of real things. It's most likely a database issue, as input of that value works as expected. Putting it into a number Hub Variable results in null instead of the value. It hardly rises to what I'd consider a reportable bug.

Platform Version 2.3.4.117
Hardware Version Rev C-7
Using Safari

"This is correct. You can change it, but it doesn't try to keep up."

Ok, I just thought it odd, because obviously the app does keep up in other places.

Can't reproduce the AM/PM problem on Safari / Ventura -- works as expected.

Ah, I'm on Catalina, so an older version of Safari. That must explain it.

Not sure. There were scattered reports about this. At one point I thought it was new in Ventura, then it went away. Very odd behavior,

We strongly recommend Chrome, on Mac and PC. Safari is just an oddball browser.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.