guiguem
commented
7 years ago From @laroque on December 3, 2015 0:14
An update to the details:
1) Provider should implement self._check_internal_status() which by default schedules a call to itself (in the same way as is done in loggers) and returns no errors (an empty list) 2) Providers for instrument would override the method and include a get() to a local endpoint which returns any error messages (it is important that if there are multiple errors present, it reads/clears them all). If the result of the get is not "no errors", the errors are recorded using a logger.critical() message (this results in it being sent to skype and any similar message distribution method we may later implement). The method then calls super() to ensure another check is scheduled after some set delay (10 minutes by default?) The errors found should be returned in a list form. 3) The self.send() method of Provider is modified to call self._check_internal_status() so that after sending a request, errors are checked and cleared. If any errors are returned, they can be included in the reply message to the request in the payload. Depending on the situation, they should potentially also result in a modified return code or return message in the Reply.
From @laroque on December 2, 2015 6:13
In the case of an instrument, this method would check if there are any messages in the error buffer.
There are two uses: 1) Providers which talk to instruments should check for errors on some interval (every few minutes?) just to ensure that the buffers remain clear. If errors are found these should be posted to slack. 2) the send() method should call this after completing requested actions for some endpoint and include any discovered errors as either extra content in the payload and/or in the return code and message of the reply message
Copied from original issue: project8/dripline#146