Workflow debug blog with levels

Feature Request
1

Hi there,
would love to have a debug level similar to logging in python:
https://docs.python.org/3/library/logging.html

Level Numeric value
CRITICAL 50
ERROR 40
WARNING 30
INFO 20
DEBUG 10
NOTSET 0

This way I can decide what to view in the scroll bar without cluttering it too much.
Cheers.

2

I like that idea as well. To confirm, are you thinking that we’d add a new property to the Debug Node for a “Level” (i.e. “Warning” or “Info”) and, in the debug output console, users would have the ability to limit the output to one or more of these levels?

3

That is correct and the filtering will be based on the minimum order, so for example if min level is set to DEBUG then it will show from DEBUG to CRITICAL, whereas if is CRITICAL it will only show CRITICAL.

4

Hi @Paolo_Proxy! It’s been a long time, but wanted to follow up and let you know that this functionality was implemented in today’s release! More details here: Platform Update - Debug Filtering, Loggly Node, Resource Job Retries

Thanks again for the suggestion!

5

Hi @Sebastian_Turner,

Workflow debug message verbosity settings, which allow for the categorization and quick filtering of debug output, and mute specific debugs is a great feature to help the developing process in platform. Congratulations to Losant Team.

Other suggestions in the context of debugging that would assist in the development of workflows on the platform would be:

  • The ability to filter debug messages based on properties.
    Currently, when it’s necessary to search for a specific debug message from a constantly running flow, it can be quite time-consuming to find it. Sometimes it’s necessary to modify the flow by adding a conditional block before the debug, filtering by a specific condition, such as {{experience.user.email}} == “user@example.com”.
    Therefore, a suggestion would be to have a debug filters tab next to debug options in the debug tab, which would filter the debug messages displayed on screen based on the condition passed in the filter, or the ability to open a separate tab, similar to what happens in the payload tester, that allows for filtering between the debug messages already loaded (which can be a filter only in the interface, and not necessarily in the debug API). A more advanced option, similar to mute in the debug node, could be filtering directly in the node, which would already filter the debug messages in the API.
    Normally, to investigate specific workflow scenarios, what I ended up doing was using an external script listening to the workflow’s debug API https://api.losant.com/applications/{applicationid}/flows/{flowId}/debug, and saving the debug messages to files for later analysis, being able to apply filters to find exactly the cases I was looking for.
  • Therefore, another possibility would be to select the debug messages in the platform interface and export/download a JSON file with these messages to facilitate analysis when there is a large quantity of debug messages arriving at the same time.

Thanks!

6

Hi @Vander_Maziero !

Thanks for the feedback. Filtering the debug stream by the Debug Nodes’ “Message” field has been suggested in the past, so I added a +1 to that feature request.

7

With last week’s release, the workflow debug log can now be filtered by entries whose message matches the provided filter. This should hopefully make it easier for our users to find specific messages in the log panel.

Thanks for the feature suggestion!