Allow to run rules using scheduler to avoid "Failed to execute rule ‘{}' with status '{}'" error path about openhab-core HOT 6 OPEN

If this is just additional functionality then I've no concerns. I misunderstood and thought the proposal was to change the current behavior which could cause some problems.

from openhab-core.

I don't have that power. A maintainer needs to come along and review the PR.

from openhab-core.

I commented on the PR because I didn't see this issue at first. Here is a better place to have the discussion.

This might be a breaking change. Right now when one rule calls another rule, the call blocks until the called rule returns.

For example:

console.info('Calling rule');
rules.runRule('longrunning', {}, true);
console.info('Rule returned');

with longrunning

console.info('Long running rule called');
Java.type('java.lang.Thread').sleep(5000);
console.info('Sleep done');

produces the following output:

2024-01-29 11:06:35.142 [INFO ] [nhab.automation.script.ui.scratchpad] - Calling rule
2024-01-29 11:06:35.978 [INFO ] [hab.automation.script.ui.longrunning] - Long running rule called
2024-01-29 11:06:40.997 [INFO ] [hab.automation.script.ui.longrunning] - Sleep done
2024-01-29 11:06:40.997 [INFO ] [nhab.automation.script.ui.scratchpad] - Rule returned

If I understand this proposal that behavior would change and the call to runRule would immediately return. This could break some end user's rules if they depend on this blocking behavior.

from openhab-core.

Hello)

It’s not a change, but an addition.

runNow methods of the org.openhab.core.automation.RuleManager are still in place and work the same way as before.

It’s up to automation scripting addons maintainers/designers to decide how to expose new calling methods (instead or besides the existing) and whether to expose them at all.

My aim is to expose some API for running rules to the Groovy scripting without the need to resort to getting services from the OSGi and without errors on parallel execution.

I thought this PR would be a good first step.

from openhab-core.

Talking about code snippets.

As I’ve said earlier, it’s up to maintainers/designers of an addon to decide how to expose new API.

One way to solve an issue with immediate return and reordering would be to wait for a Future from one of the newly proposed scheduleRun methods to complete.

Awaiting can be done inside the addon and not be exposed to the addon user/script writer.

Another way can be to return Future/Promise from the runScript (or any new additional method/function to expose new calling method) and let user to decide what to do.

As far as I understand, snippets are JS scripting examples. Unfortunately, I’m not familiar with JS scripting addon internals and not confident that there are no pitfalls with proposed strategies to mitigate early return from scheduleRun.

If you have a proposal on how to make an API more convenient or useful - I’m all ears.

from openhab-core.

In case there's no more objections, can someone approve pull request?

from openhab-core.