Empty msg on Modbus fail

[unborn-andy]

Which node-red-contrib-modbus version are you using?

5.43.0

What happened?

Following on issue #347
and recent discussion in Node-red forum
https://discourse.nodered.org/t/trouble-with-unreliable-modbus-flex-getter/94843

Some checks were introduced a few years back in the Modbus nodes code.
invalidPayloadIn
isNotReadyForInput
isInactive

that kinda broke the functionality of sendEmptyMsgOnFail because the code in the try catch L227 is never reached when a device isInactive or isNotReadyForInput.

Would it be possible to send a sendEmptyMsgOnFail in those cases also along with the verboseWarn ?

Im not a developer so im not sure how to make a proper PR

Example code :

node.on('input', function (msg) {
      const origMsgInput = Object.assign({}, msg)
      
      if (mbBasics.invalidPayloadIn(msg)) {
        /* istanbul ignore next */
        verboseWarn('Invalid message on input.')
        mbBasics.sendEmptyMsgOnFail(node, new Error('Invalid message on input.'), origMsgInput)
        return
      }
      if (node.isNotReadyForInput()) {
        /* istanbul ignore next */
        verboseWarn('Inject while node is not ready for input.')
        mbBasics.sendEmptyMsgOnFail(node, new Error('Inject while node is not ready for input'), origMsgInput)
        return
      }
      if (modbusClient.isInactive()) {
        /* istanbul ignore next */
        verboseWarn('You sent an input to inactive client. Please use initial delay on start or send data more slowly.')
        mbBasics.sendEmptyMsgOnFail(node, new Error('You sent an input to inactive client. Please use initial delay on start or send data more slowly.'), origMsgInput)
        return
      }

      messageQueue.push(msg)
      processNextMessage()
    })

Server

Other/External server

How can this be reproduced?

Make a modbus request to a device that is offline .. with Empty msg on Modbus fail checked.
It does not produce an error msg like it used to since version 5.23.3 so it can be later handled in the flow.

What did you expect to happen?

To produce an error msg .. and also keep the original msg properties so the failure can be traced / handled.

Other Information

No response

[SindreLindahl]

I also get no errors or unstable error handling on devices that are online, but where the requests often fail.

We are working with a lot of different protocols, and from a I/O overview, I don't care so much whether it is modbus, bacnet, http, db request or anything else. The key purpose is to read/write some data from an external resource. And regardless of what that is, I would always like to get a message back, regardless of whether the request is sucessful or fail. That could be empty message or to throw an exception to be caught. At the moment I'm not getting any output what so ever in some of my use cases.

[github-actions]

This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.

[ryanluton]

Also seeing this behavior - causes a split + (automatic) join to fail as the msg.parts are never fully returned.

[github-actions]

This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.