continuous-integration/drone/push Build is passingDetails
- Fixed regression introduced by incorrect format string in `exec`.
- LINT for the `procedure` module.
- Apply `Message.Encoder` when dumping values from the context.
- The following logging namespaces are now used, to make it easier to
filter only log lines related to the logged application message:
- `platypush:events`
- `platypush:requests`
- `platypush:responses`
- Those messages are always logged as JSON, with no prefixes nor
suffixes.
- Requests are always logged when executed - no more delegation to the
upstream backend.
- Responses are always logged when fully populated (including `id`,
`origin`, `target` etc.), instead of being logged when still partially
populated. This makes it particularly easy to link request/response
IDs directly from the logs.
The `disable_logging` attribute was only available on events and
responses, and it could only either entirely disable or enable logging
for all the events of a certain type.
The new flag allows more customization by setting the default logging
level used for any message of a certain type (or `None` to disable
logging). This makes it possible to e.g. set some verbose events to
debug level, and the user can see them if they configure the application
in debug mode.
It also delegates the logging logic to the message itself, instead of
having different parts of the application handling their own logic.
- Refactored the logic for executing a request and wrapping the response common to procedures, crons and event hook decorators into platypush.common.exec_wrapper
- Added mock getvalue() method to Logger to prevent PyCharm failures in the tests when sys.stdout is redirected to the Logger object
- Added set/cler timeout/interval actions in the utils plugin to
dynamically set or stop timed actions from your custom logic
- Actions error handling refactoring. If a Response is processed with
some errors, then just log the error and return it to the caller,
without raising an exception. If instead the action execution raised an
uncaught exception, then handle the retries properly and return errors
as a list with the output from all the retries, without being too
verbose with the returning and logging the whole stack trace multiple
times.
- Using `@action` annotation to indicate methods that are allowed to be
executed as actions
- The output and errors of an action are automatically wrapped into a
`Response` object without any response build required on the plugin side
Fabio Manganiello
Fabio Manganiello