Open rmv5004 opened 3 weeks ago
This has also been an issue if I pass an HTTP response directly. Below is an example. My thought was the item node would only look at the msg.payload. However sending the complete HTTP response causes a BadWriteNotSupported error.
{"_msgid":"b31c8324651e4fb0","payload":"{\"apiVersion\":\"4\"}","token":"9m-ZVlicFFxspMQ3HQM3lz4zsG4KXObEZwVA6K3RgB-UmA","post":{"machineStatus":6},"path":"api.app:30000","endpoint":"/api/heartbeat","statusCode":200,"headers":{"server":"nginx/1.18.0 (Ubuntu)","date":"Mon, 04 Nov 2024 16:19:10 GMT","content-type":"application/json; charset=utf-8","content-length":"39","connection":"close","request-context":"appId=cid-v1:","x-powered-by":"Express","etag":"W/\"27-6z5uQYcJmYspNqJiQGo4hmPJJcA\"","x-node-red-request-node":"16f99214"},"responseUrl":"https://api.app:30000/api/heartbeat","redirectList":[],"retry":0}
This seems to be a specific issue with release 2.337. I do not get these errors when running 2.332.
I expect this was unseen as I implemented feature to write sourceTimestamp / statusCode. Removing msg.sourceTimestamp / msg.statusCode from the msg object will fix this. As your OPC UA Server does not support writing these you have to remove those from the msg object.
Any chance this can be an option check box or a soft error? It seems to be a hard fault that causes a restart.
I have to take a look... perhaps.
Client node has now option to set status & timestamp.
By default it is off as most of the servers are actually not supporting setting these.
Should the Item Node check / verify the msg to make sure the Client Node will not fail? This way the user will know which piece of the flow to fix vs the client disconnecting due to an unable to write value error. And/Or should the BadWriteNotSupported error include the item?