Cache.private.get defaultSupplier is always called

Setup, Configuration and Use Scripts & Rules
1

Using JavaScript scripting.

When the call to cache.private.get is given a defaultSupplier, I expected that defaultSupplier would only be called if there was no entry in the cache, but it looks like it is called every time.

With this code:

console.log('cache', cache.private.get('tm'));

const id1 = cache.private.get('tm', () => {
  console.log('function called');
  return 5;
});

console.log('id1', id1);

The first time it is run:

17:10:09.637[INFO] [openhab.event.RuleUpdatedEvent] - Rule 'scratchpad' has been updated.
17:10:11.533[INFO] [org.openhab.automation.jsscripting.rule.scratchpad] - cache null
17:10:11.535[INFO] [org.openhab.automation.jsscripting.rule.scratchpad] - function called
17:10:11.536[INFO] [org.openhab.automation.jsscripting.rule.scratchpad] - function called
17:10:11.538[INFO] [org.openhab.automation.jsscripting.rule.scratchpad] - id1 5

Then the second time:

17:20:10.591[INFO] [org.openhab.automation.jsscripting.rule.scratchpad] - cache 5
17:20:10.594[INFO] [org.openhab.automation.jsscripting.rule.scratchpad] - function called
17:20:10.598[INFO] [org.openhab.automation.jsscripting.rule.scratchpad] - id1 5

Ignoring for now that on the first run, the function is called twice, am I right that the function should not be called on the second run?

2

I suspect the reason the function is called twice on the first run is the reason why the function is called once on the second run.

To answer your question, no, the function shouldn’t be called if the cache already has a value.

3

I must admit that I do not know of a situation where this causes a problem. I just noticed when playing around.

In the case of

var timers = cache.shared.get('timers', () => TimerMgr());

the ‘second run’ TimerMgr object will quietly go away when it goes out of scope, but it don’t know how others are using it.

It looks like the JS binding delegates the call to a core function. Should I raise a bug report, and where?

4

I don’t think we have enough information to know where to raise the issue in the first place.

Are you using managed rules or file based rules?

I ran the code above in scratchpad and can confirm the behavior.

Are you sure it’s the second TimerMgr or is it the first one?

Is the TimerMgr that gets returned and set to timers the one that gets saved to the cache, or is that instance the one that gets lost (losing any timers that may have been added to it on that first run)?

5

Yes I’m using the scratchpad as well.
openHAB 5.1.3, openhab-js version: 5.17.0, OHRT version: 2.1.0

By ‘second run’ I actually meant when the script is run a second time.

Adding a bit more:

let counter = 3;
console.log('cache', cache.private.get('tm'));

const id1 = cache.private.get('tm', () => {
  console.log('function called', 'counter:', counter);
  return counter++;
});

console.log('id1', id1);

First run:

2026-02-23 17:14:57.874 [INFO ] [openhab.event.RuleUpdatedEvent ] - Rule 'scratchpad' has been updated.

2026-02-23 17:14:59.166 [INFO ] [tomation.jsscripting.rule.scratchpad] - cache null

2026-02-23 17:14:59.167 [INFO ] [tomation.jsscripting.rule.scratchpad] - function called counter: 3

2026-02-23 17:14:59.167 [INFO ] [tomation.jsscripting.rule.scratchpad] - function called counter: 4

2026-02-23 17:14:59.167 [INFO ] [tomation.jsscripting.rule.scratchpad] - id1 4

Second run:

2026-02-23 17:15:16.019 [INFO ] [tomation.jsscripting.rule.scratchpad] - cache 4
2026-02-23 17:15:16.020 [INFO ] [tomation.jsscripting.rule.scratchpad] - function called counter: 3
2026-02-23 17:15:16.020 [INFO ] [tomation.jsscripting.rule.scratchpad] - id1 4

So it’s the second call to the function (in the first run) that actually gets stored in the cache.

1 Like
6

It’s an openhab-js issue, have just created a fix for it: [cache] Fix defaultSupplier called on every get invocation by florian-h05 · Pull Request #518 · openhab/openhab-js · GitHub

You can download the dist-without-license artefact from the PR checks:

Put the openhab.js into your node_modules, turn off Cache openHAB JavaScript Library Injection in the JS Scripting add-on settings, resave your script, and report if that fixes the issue.

1 Like
7

I tested this on my (oldish) snapshot 5.2.0 and it works.
Thank you.

1 Like
8

Thanks for confirmation :+1:
I would recommend removing the openhab.js file and either go back to the add-on included library version or manually handle it through npm – I will push a new release with the bug fix soon.