`Messenger.query()` result printed explicitely as `ans` in the receiving session, if not properly processed

[EastEriq]

(branch gledmagicwater) I observe it often in master terminals spawned by a superunit, while the MultiPanel monitor is running. It should be easy to reproduce sending a long command which keeps the session busy on the Messenger, and querying the Responder, or something the like. I think at one point in time I also knew why this happens, in Messenger.datagramParser.

[EastEriq]

Quick way to reproduce:

Unit=obs.unitCS('11')
Unit.connectSlave(1:2)
Unit.Slave(1).Messenger.send('pause(10)')

with the focuser attached and while the Multipanel is periodically querying Unit.Focuser{1}.Status; on the Responder channel (I guess I could do the same from the master session)

>> ans =
    'idle'
>> ans =
    'idle'

[EastEriq]

Note that by default defining the Unit in an interactive session, the Slaves are xterms, and their MasterMessengers are Messengers (in contrast with Listeners as default when called by a superunit). Hence the pause() received by the MasterMessenger is run inside a callback, which cannot be interrupted by the query on the Responder. Hence, "tooLateToReply".

[EastEriq]

~I suspect a corner matlab bug of evalin() in https://github.com/EastEriq/LAST_Messaging/blob/63cdeb747f1ea19199760603eca8d53d52ff72d5/%2Bobs/%2Butil/%40MessengerCommon/executeCommandAndReply.m#L74. There, for tooLateToReply, we have already appended a ';' to the command; nevertheless the output is printed. Plain evalin('base','a=1;') as well as~

>> test= @() evalin('base','a=1;')
>> test()

~produce no output though. Maybe because we are in a callback?~

In any event, it is a conscious choice to evaluate the command even if we are late, but not to return the answer. The assumption is that the command could have side effects (e.g. connect a device) which are desirable, even if the sender does not consider the reply relevant anymore.

Ps: the issue should be transferred to https://github.com/EastEriq/LAST_Messaging

[EastEriq]

Can't come up with a deep understanding of what to improve, so I just went for the workaround of semicoloning the offending classCommand query coming from the Superunit monitor, commit https://github.com/EastEriq/LAST_SuperunitMonitoring/commit/5dff450842ff44750eeaa5a5916798a29a92c49e