UP/DOWN + or - values are changed when saving a rule configuration

[shaunBrazendale]

SMUI version : 3.14.0

Bug.

When editing an existing rule containing UP/DOWN rules the + or - values are changing when we save the new rule configuration

Repro

see attached video link, notice the UP rule 3rd from bottom changes from UP+++++ to DOWN- upon save of config

https://www.loom.com/share/deca7978688847cd96f8fe35014d2023

[renekrie]

@pbartusch This somehow rings a bell. Didn't we fix this bug in an earlier version?

[epugh]

I checked closed issues and didn't see anything, and nothing in the release notes either. Maybe time to start a CHANGES.md file?

[renekrie]

There are release notes on docs.querqy.org but I couldn't find anything related

[depahelix2021]

Hi shaunBrazendale, I'm trying to reproduce this locally, and I'm unable to reproduce it. If you create a brand new rule set with no other rules in it, does it still happen? Is this the only context you have seen this, or are there other examples that you can give?

[depahelix2021]

Do you know if you are setting a custom value for the environment variable SMUI_CUSTOM_UPDOWN_MAPPINGS?

[depahelix2021]

Do you have access to the mysql database backing your SMUI instance?

[shaunBrazendale]

Hi shaunBrazendale, I'm trying to reproduce this locally, and I'm unable to reproduce it. If you create a brand new rule set with no other rules in it, does it still happen? Is this the only context you have seen this, or are there other examples that you can give?

Hi @depahelix2021 so a brand new rule set seems to be ok. The issue occurs in a rule set with "many" rules I would say greater than 5 using mostly up/down - and a mixture of both up and down rules.

We use the out of the box up down boost values too.

I can't get you access into our mysql, the security beaurocracy would take too long. But if you are sturggling to repro it, I reckon we can pair up and look at the db over a call

[shaunBrazendale]

@depahelix2021 so another example from another smui instance we run (we have 5 or so seperate instances) . So this example again is a rule set with a lot of up/downs. The user says when they save the first time some of the up/down values change, but if they modify the value to the expected value again and save it is ok. So the second save is fine

[depahelix2021]

Thanks for the additional information. How many people have access to the interface? Is it possible that multiple people are working on the same rules at the same time and overwriting each other's changes? Is it harder to reproduce during off-hours? Do the UP/DOWN values always change in the same way (5 up to 1 down) or is it seemingly random in different directions and amounts? Do the ones that change always change to a certain other selection, or is it seemingly more random than that?

[depahelix2021]

When could we meet to do a screen share? I'm Boston, MA, USA (EST).

[shaunBrazendale]

SO i need a few guys my-side too, how about Monday afternoon central european time?

[depahelix2021]

We have daylight savings time here ending this weekend. CET right now is 5 hours ahead of EST, but next week will be 6 hours ahead. Monday morning my time I have a meeting until 10 AM EST, so I can realistically only do 4:30 PM CET to 5PM CET Monday (or anytime later than that). Tuesday I could meet as early as 2 PM CET, as you like.

[shaunBrazendale]

yeah ok, 4.30pm cet on monday is great.

[depahelix2021]

Email me cmorley AT opensourceconnections.com so we can set up a meeting, how to meet (Zoom?), etc.

[depahelix2021]

Thank you to Shaun, Charline and Ramzi from Rubix for showing me this bug on an hour long call today.

tldr; Probably if we avoid using the "UP(+++++)" setting, you'll see less issues for now, until we can publish a bug fix for this issue.

I have reproduced the bug now.

You must have 3 up/down rules at least.  Unexpected value changing behavior differs depending on how many up/down rules there are for the search_input. No other types of rules are needed to reproduce this.You must be using specifically the "UP (+++++)" value in at least one of the rules.You must save two times in a row to see surprising value changes occur.

The first save to the database works correctly, and the screen echos the correct values.  If you save one additional time however, the wrong values are persisted to the database and then the new values show on screen, corresponding to the new database values, however no humans clicked to make any changes!

So, I think it must just be something to do with values syncing incorrectly between or within the model and view. Some logical bug looping through and trying to recalculate boost values or break ties, or something like that. Don't know yet, but..

The bug may be somewhere in rule-management.component.ts

Another thing I've noticed (probably not important) is that on my default smui, the max value +++++ corresponds to 750 boostMalusValue, whereas for Rubix, that value is 500 (same thing for "DOWN(-----)".  The other values are all the same in both places: 5, 10, 50, 100. Rubix said they are not using custom settings for the mappings, so I'm not sure why my smui and their smui don't align on that number, even though supposedly it is the same version of the app.  Could it be the difference between o19s smui and querqy smui perhaps?

If possible, if we can avoid using the "UP(+++++)" up/down rule setting value and use the other 9 values only just for now, we'll see less unexpected behaviors (or no unexpected behavior?), giving us time to publish a bug fix.

[depahelix2021]

I found the bug and I'm working on a fix. It will be a small fix, and it is definitely a bug.

[depahelix2021]

This is the fix #120

[shaunBrazendale]

@depahelix2021 super thanks!! Do you know when we can expect a new release?

[depahelix2021]

I don't know exactly yet but I will try to lobby for that soon and find out for you!

[shaunBrazendale]

no problem. That works for us

[depahelix2021]

PR #120 now, not PR #119

[depahelix2021]

Shaun, please see here for latest image with the fix: https://hub.docker.com/r/querqy/smui/tags