Motivation

Based on our co-engineering experience with Ford, we identified the need to enhance the developer experience within the management console and developer UI (dev UI).

Description

When a user accesses the workflow instance page, the following information should be clearly presented:

HTTP Request/Response Logging in Workflow Console

For any state that invokes an operation of type rest (OpenAPI), the corresponding HTTP request and response should be logged and accessible in the console. This includes the body and headers of both the request and response. Having this visibility helps developers understand what arguments were passed and diagnose issues during development.
By default, these logs are available only in dev mode, but they can be enabled in other environments for troubleshooting purposes via configuration.

Display JQ Expression Results Per State

For tasks that use JQ expressions, the evaluation results should be displayed in the management console. This provides transparency into how data is being transformed and enables developers to inspect values easily. Like other debug features, this information is shown by default in dev mode and can be optionally enabled elsewhere.
This significantly improves the debugging and introspection process during workflow execution.

Incoming and Outgoing Events

All events that are received or produced during a workflow’s lifecycle should be visible in the console. This event trail is essential for understanding the flow of data and verifying system integration points.
As with other debug information, event tracking is enabled by default in dev mode and can be configured for other environments as needed.

Risks and Assumptions

Storing and exposing all of this information, even in dev mode, may impact platform storage and overall workflow processing performance. For this reason, these detailed logs and audit trails are enabled only in dev mode by default. In other environments, they are disabled by default and can be selectively enabled per workflow via platform configuration. This ensures developers' flexibility while maintaining the platform's stability and efficiency in production scenarios.

Component Assessment

• Runtimes/Applications
  Responsible for collecting and caching the necessary data (HTTP logs, JQ results, and event traces) to make it available for the Management Console and Dev UI.

• Operator
  Provides the runtime infrastructure needed to store, manage, and serve the debug and audit data. This may involve extending volume configurations or introducing new persistence mechanisms as required.

• Tools (Management Console/Dev UI)
  Ensures that all collected data is clearly and effectively displayed to users. This includes UI components for viewing HTTP request/response logs, JQ evaluation results, and event traces directly in the workflow instance view.