[bug-11240]sendRequestAsync

I noticed that the behavior of sendRequestAsync blocks the UI and the callback fires twice.
Is this expected?

system.util.sendRequestAsync(project='p', messageHandler='mh', payload={'Id':1}, onSuccess=callback)

Is it possible your callback is what’s blocking? The callback is invoked on the UI thread.

Possibly, but why does it get invoked twice?

Don’t know, maybe a bug? It’s certainly not intentional. Does it happen if you create a new script and callback? Have you added logging to see if sendRequestAsync is being called twice or just the callback?

sendRequestAsync is called once
onSuccess callback is called twice

Without defining onSuccess, the UI is blocked on sendRequestAsync call.

With ignition 7.9.9 this still seems to be unsolved.

While there is a bug here (onSuccess added as a kwarg gets fired twice) I wasn’t able to reproduce the blocking behavior.
To fix the double callbacks, just append the callback separately, ie:

future = system.util.sendRequestAsync("Test", "echo", {'message': 'message'})
future.onSuccess(handler)

rather than:

future = system.util.sendRequestAsync("Test", "echo", {'message': 'message'}, onSuccess=handler)
2 Likes

Haven’t seen the block behavior either, was referring to the double call of the success handler.

Also, noticed that assigning an error handler using kwargs doesn’t work, the error handler is never fired, however using the onError method to assign it, causes it to fire twice aswell.

I am experiencing the same thing. onError handler not firing when assigned as an argument. When assigning the handler via a method it fires twice.

I’m still experiencing the the same behavior when setting the callback in this manner handle.onSuccess(onSuccesFunc)

My request handler in the gateway is returning a python dictionary with 3 entries, the values being byte arrays. The client onSuccess function is extracting those bytes from the response and writing them to files. My callback is getting triggered 1-3 times.

Yes, I filed the ticket at the time but the issue hasn’t been prioritized because the workaround is pretty easy to implement.