Improve HANLDER_INITIALIZING_ERROR so it's more understandable

[rkoshak]

The problem

When there is a fatal error in a rule it becomes UNINITIALIZED and shows a HANLDER_INITIALIZING_ERROR. The name of this error and the details are not generally understandable or actionable by the average user. For example, if the rule has a Script for a language that doesn't have the add-on installed appears as:

Your suggestion

I've several suggestions:

• Gray out the play button for rules that cannot be run becuase they are not in the Idle state. (implemented in Rules/Scenes/Scripts: Gray out run now button if uninitialized #2754)
• Improve the error message to something more understandable and actionable for the end user (in this case something like "Cannot find installed automation add-on that supports "broken" scripts". If it can be even more specific that would be even better (e.g. "This rule requires the jRuby add-on to be installed").
• Add some sort of indication to the rule page to show what component is generating the error (i.e. which trigger, action or condition the error is comming from).

Your environment

runtimeInfo:
  version: 4.3.0.M1
  buildString: Milestone Build
locale: en-US
systemInfo:
  configFolder: /openhab/conf
  userdataFolder: /openhab/userdata
  logFolder: /openhab/userdata/logs
  javaVersion: 17.0.12
  javaVendor: Debian
  osName: Linux
  osVersion: 6.8.0-41-generic
  osArchitecture: amd64
  availableProcessors: 4
  freeMemory: 148337520
  totalMemory: 494927872
  uptime: 932
  startLevel: 70
addons:
  - automation-jsscripting
  - automation-jsscriptingnashorn
  - binding-amazonechocontrol
  - binding-astro
  - binding-chromecast
  - binding-http
  - binding-ipcamera
  - binding-mail
  - binding-mqtt
  - binding-network
  - binding-networkupstools
  - binding-openweathermap
  - binding-shelly
  - binding-vesync
  - binding-zigbee
  - binding-zwave
  - misc-openhabcloud
  - persistence-mapdb
  - persistence-rrd4j
  - transformation-basicprofiles
  - transformation-jinja
  - transformation-jsonpath
  - transformation-map
  - transformation-regex
  - ui-basic
  - ui-habot
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: false
    macos: false
    windows: true
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    os: windows
    pixelRatio: 1
    prefersColorScheme: light
  isSecureContext: false
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 4
    language: en-US
    languages:
      - en-US
      - en
    onLine: true
    platform: Win32
  screen:
    width: 1600
    height: 900
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: light
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
    blocklyRenderer: null
  userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
    like Gecko) Chrome/128.0.0.0 Safari/537.36
timestamp: 2024-09-11T21:03:39.099Z

Additional information

[florian-h05]

FYI I have just implemented your first suggestion.

[florian-h05]

Wrt to the second suggestion: This is openHAB core part, and when I tried to look into it I could not reproduce your described scenario, I don't get that message. If the automation add-on is missing, my rule does not show any error in the UI but only on execution in the log.

[rkoshak]

Maybe it behaves differently in the snapshots? I'm on 4.3 M1.

What I did to get that error to simulate a not installed add-on was add an inline script action then changed the mimetime to "application/broken". I should have posted my test rule.

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: TestSwitch
    type: core.ItemStateChangeTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      type: application/javascript
      script: console.info('Test rule condition');
    type: script.ScriptCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript
      script: console.info('Test Rule action');
    type: script.ScriptAction
  - inputs: {}
    id: "3"
    configuration:
      type: application/broken
      script: console.info('Broken Test Rule action');
    type: script.ScriptAction

Maybe I went about testing what happens when the add-on is not installed in a bad way?