This section describes guidelines put in place by Styx authors – they should be helpful in making some common everyday coding choices trivial and consistent, which helps development speed and quality.
Choose a log level accordingly:
errorwhen a problem is encountered that was not supposed to occur by design. A "This should never happen" type of thing, symptomatic of a Styx bug.warnwhen Styx cannot run a workflow or respond to an API call; e.g. an external system being down. (Note: Styx design is presumed to be resilient to intermittent failures in the first place, therefore an external system being temporarily down is not a Styx error and should not inevitably lead to one.)infofor other significant occurrences; e.g. starting and stopping, responding to API calls.debugfor other occurrences, uncertain significance but possibly helpful in troubleshooting; e.g. workflow instance state transitions.
Problems that are likely user errors (for example, an ill-formed workflow schedule configuration)
should first and foremost be exposed to the users, by inserting an informative message in the error
event. Additionally they can be logged in Styx logs as info or lower.
Ideally the error and warning logs should be usable as the intuitive starting points in troubleshooting situations. This is to say that they should not be spammy. Batch warnings, employ best practices of backoff and caching.