error

[EastEriq]

don't know what this is. Speculation, because .park takes longer than the http timeout?

>> M.goTo(89,87,'ha')
>> M.Status
ans =
    'fault'
>> M.park
>> M.Status
14:10:53.298 [INF] Exception: MATLAB:json:ExpectedLiteral - JSON syntax error at line 1, column 1 (character 1): expected 'Inf' but found 'Internal'. -  - Remote.send: (dialect='LAST'): [FAILURE] duration=0.111, URL='http://127.0.0.1:8000/last/api/v1/mount/Status'
Error using matlab.net.http.RequestMessage/sendOneRequest (line 1522)
JSON syntax error at line 1, column 1 (character 1): expected 'Inf' but found 'Internal'.
Error in matlab.net.http.RequestMessage/send (line 486)
                    obj.sendOneRequest(connector, options, CredentialInfo.empty,
                    CredentialInfo.empty, ...
Error in obs.api.Remote/send (line 119)
                [Response, ~, ~] = Request.send(Url, Obj.HTTPOptions, Consumer);
Error in obs.api.wrappers.mount/get.Status (line 795)
                    Out = Obj.Remote.send(ArgsCell{:});
Caused by:
    Error using jsondecode
    JSON syntax error at line 1, column 1 (character 1): expected 'Inf' but found
    'Internal'.
Error using jsondecode
JSON syntax error at line 1, column 1 (character 1): expected 'Inf' but found 'Internal'.
Error in matlab.net.http.io.internal.StreamingJSONDecoder/convert (line 36)
                    obj.ConvertedData = jsondecode(char(obj.Data));
Error in matlab.net.http.io.JSONConsumer/putData (line 86)
                [jsonData, ~] = obj.Decoder.convert(data, obj.DecoderArguments{:});
Error in matlab.net.http.io.ContentConsumer/putDataInternal (line 976)
                    [size, stop] = obj.putData(data);
Error in matlab.net.http.io.ContentConsumer/closeInternal (line 919)
                obj.putDataInternal(uint8.empty);
Error in matlab.net.http.internal.HTTPConnector/copyContentToByteArray (line 579)
            byteArray = copyContentToByteArray(obj.Connection, savePayload);
Error in matlab.net.http.internal.readContentFromWebService (line 206)
                payload = connector.copyContentToByteArray();
Error in matlab.net.http.RequestMessage/sendOneRequest (line 1371)
                            readContentFromWebService(connector, 0, ...
Error in matlab.net.http.RequestMessage/send (line 486)
                    obj.sendOneRequest(connector, options, CredentialInfo.empty,
                    CredentialInfo.empty, ...
Error in obs.api.Remote/send (line 119)
                [Response, ~, ~] = Request.send(Url, Obj.HTTPOptions, Consumer);
Error in obs.api.wrappers.mount/get.Status (line 795)
                    Out = Obj.Remote.send(ArgsCell{:}); 
>> M.HA
ans =
     []
>> M.Status
ans =
     []

In stdout, the log still shows periodically "AnswersToProbe":true for the mount probe.

[EastEriq]

Since that, all http requests to the mount address time out after 10 seconds; both via the uvicorn webby and via matlab (even after deleting and recreating M=obs.api.makeHttpApi('Location','LAST.1.unit11.mount');.

[EastEriq]

got it again today after sending the mount to .goTo(...'eq'), which is also a blocking function which may take ~20 sec

[blumzi]

Why is .goTo() blocking?

[EastEriq]

Specifically now, because set.RA is based on a tight polling loop. It is to ascertain whether I can achieve a comparable pointing precision switching to a timed polling, which would free the main loop and make it responsive to further lipp messages. There would be also the issue of preventing probing commands because polling communication with the controllers is in progress. Legitimate issues which call for some thoughts of redesign.

In general, though, I think that long response times are possible, since i/o is involved. I see no better solution than deciding, device by device, what is the tolerated timeout before declaring the device problematic, and trigger counteractions. Also this needs some thought on my side. However, in the first place I think that a non-responding driver process should not cause json errors, and ultimately bailout (which I suppose is what is happening as of now); no response should just be recorded as such.

[blumzi]

All these thoughts are very wonderful, but the design is for things to be launched and not waited for. I vividly remember we were both in the same room when we both decided that was the way to go. Musing now about long per-device timeouts is somewhat futile, isn't it?

[EastEriq]

It is not musing, it is simply getting to one case situation where an implementation which was empirically acceptable for interactive use needs to be rethought (how to ensure reliable pointing prediction with timers, how to inform the probing function not to interfere with ongoing communication) (actitvity bits may be a solution). I'm not complaining about them, but about the disrupting json error.