[BUG] setVariable occasionally doesn't set anything (especially when you use 2 shortcuts in turn} )

[royyeh22]

Steps To Reproduce

3 of them are all advanced scripting shortcut (no http request).

1. read db_fan first

2. Click on "set 1"

3. click read db_fan

4. go global variable to check its value

Expected behavior

correct value read after each update

Actual behavior

value isn't set all the time when setVariable called.

Context

Please complete the following information:

• App Version 4.5

The setVariable sometimes does work at his first time, but only in a ratio less than 0.1.
If we click ’set 1’ and ’set 2’ in turn, db_fan would keep showing his initial value for several times, untill one of them occasionally does his job.

Is this because of some cache machanism? (i didn't see this issue on another device)

[royyeh22]

additional info: if we click 'set 1' TWICE and then 'read db_fan', 100% value is changed from anything else to "1" in db_fan.

[royyeh22]

// shortcut "set 1"

var DB = "db_fan";

//showDialog(d, DB)
setVariable(DB, '1');
setVariable(DB, '1'); // now we have to workaround by calling this twice, to make db_fan set as we want.
showDialog(getVariable(DB), DB)

[royyeh22]

// shortcut "set 1"

var DBuuid = "59c5cb43-21f4-411f-b249-8c1e2e3649a1"; // by using uuid, it never skips the setVariable() call.
setVariable(DBuuid , '1');
showDialog(getVariable(DBuuid ), DBuuid )

name resolution issue?

[Waboodoo]

That is an interesting bug. So far I have no explanation for it. There is no cache involved, so that can't be it. Internally, variables are uniquely identified by their UUID. So if you set a value via UUID, it can directly apply it, but if you instead set a value via the variable's key, the app first has to look up the variable to find out its UUID. If this fails, it will treat the variable as a local variable and only set its value in memory. So I suspect that somehow this resolution sometimes fails, though I don't know why.

Could you attach an export of these 3 shortcuts, so I can inspect it in more detail?

(i didn't see this issue on another device)

Does that mean this behavior only shows up on one device but not others? What devices are these? OS version, manufacturer, model?

[royyeh22]

shortcuts_bug.zip

yes. only on this phone. android 12.
realme x3.

set 11 usually fails. others always work.

I was thinking whether it helps if you can

1. return errors when setVariable failure
2. provide any option to disable smart local determination, forcing only looking up in global.
3. provide a similar ui like long-pressing on a global variable to obtain its uuid.

the most interesting thing is...
it always sets the global variable db_fan correctly after click twice (two proceses), no matter in what frequency.

[royyeh22]

this is weird too.

// get then set 11

var DB = "db_fan";

//showDialog(d, DB)

showToast(
getVariable(DB)); //failed if local; but it passes

setVariable(DB, '11');

showDialog(getVariable(DB), DB)

steps:
value in db_fan is 22.
then, click this shortcut.
global resolution passed. 22 toasted. 11 set (expected).
read db, but we got 22 still.
wait until toast gone(or even 15 sec later), read db again. 22 still.

looks like it somehow only updates in-memory (at the first time we click the shortcuts)
or my database needs some warm-up !?

[Waboodoo]

Ok, thanks for the details, I think I figured it out:

When you edit a global variable, it creates a special temporary entry in the database for the variable being edited. This virtual variable should normally be deleted when you close the variable editor, but it apparently doesn't always do that. So now whenever you try to set that variable's value by name, there's a chance that the database will instead update the virtual variable instead of the real one, because they share the same name. They don't share the same UUID, so updating by UUID always works. This would explain why it only fails sometimes, and why it doesn't seem to fail on one of your devices, because it essentially depends on which variable you most recently edited. Can you try creating a new variable and then check whether you can still reproduce the problem?

I will include a fix for this in the next version.

Also, sidenote: if you put the variable's name directly into the setVariable function as a string literal instead of using a local JS variable, then that name will get converted to the variable's UUID upon saving the shortcut. The idea behind this is that it allows the app to better detect which variables are being used, and it also makes it possible to rename variables without breaking all the scripts. Also it would explain why this bug hasn't surfaced sooner, because I assume that most users use string literals, which means their variables will always be resolved by UUID, thus sidestepping the bug.

[royyeh22]

1. the most recently edited virtual variable I believe is the root cause.
   1.1 creating another global variable indeed fixed them.
   1.2 for all my tests on this phone, I always created one and tested on it, making it always the recently-edited one.
   1.3 on another device, I imported it from a zip, and never touching the global variable manager page.
   However, if there exist more variables (including the virtual one) with the same key, the looking-up order seemed swapped regularly by some logics, so that I can set the real one every twice click.

2. great to know the machanism of linking global variable and the scripts using them.
   that also explained why you can show "unused" or not on the global variable manager page.
   setVariable(/[variable]/"be325495-2025-4902-80c7-aa5f4fc97818"/[/variable]/,55);
   understand that most users prefer bidirectional mapping, but it supprised me a little bit, because I was trying to breaking the link of a variable from a script, and then to link another variable to it.
   I think I still can make it with uuids.

thanks for your great work!