Feature request: structured export of Base workflow execution logs

[shushang999-create]

Feature Request: Structured export of Base Workflow execution logs

Background

It would be very useful if lark-cli could support querying and exporting execution logs for Lark/Feishu Base workflows.

The main use case is not simply checking whether a workflow execution succeeded or failed. A Base workflow may contain many heterogeneous nodes, for example:

• Trigger nodes
• Conditional branches
• Record query nodes
• Record create/update nodes
• HTTP request nodes
• Loop / iteration nodes
• Variable or data-processing nodes
• Notification nodes
• Other workflow-specific actions

Because every node type has different inputs, outputs and execution semantics, flattening one workflow execution into a single log record cannot completely describe what happened during the run.

Suggested data model

I suggest exposing workflow execution logs using a hierarchical structure:

Workflow
└── Run
    ├── run metadata
    └── Nodes[]
        ├── node metadata
        ├── node type
        ├── execution status
        ├── start/end time
        ├── duration
        ├── input
        ├── output
        ├── error
        └── node-specific execution details

For example:

{
  "workflow_id": "xxx",
  "workflow_name": "Production Metrics Query",
  "run_id": "run_xxx",
  "status": "failed",
  "started_at": "2026-09-24T09:30:12+08:00",
  "finished_at": "2026-09-24T09:30:15+08:00",
  "duration_ms": 3241,
  "trigger": {},
  "nodes": [
    {
      "node_id": "node_1",
      "node_name": "Query records",
      "node_type": "bitable.query_records",
      "status": "success",
      "duration_ms": 532,
      "input": {},
      "output": {}
    },
    {
      "node_id": "node_2",
      "node_name": "HTTP Request",
      "node_type": "http_request",
      "status": "failed",
      "duration_ms": 1204,
      "input": {
        "method": "POST"
      },
      "output": {
        "http_status": 500
      },
      "error": {
        "code": "xxx",
        "message": "xxx"
      }
    }
  ]
}

Proposed CLI commands

A possible CLI design could be:

# List workflow runs
lark-cli base workflow-runs list \
  --app-token <APP_TOKEN> \
  --workflow-id <WORKFLOW_ID> \
  --status failed \
  --page-all

# Get one complete execution
lark-cli base workflow-runs get \
  --app-token <APP_TOKEN> \
  --workflow-id <WORKFLOW_ID> \
  --run-id <RUN_ID> \
  --include-nodes \
  --include-input-output

# Export executions
lark-cli base workflow-runs export \
  --app-token <APP_TOKEN> \
  --workflow-id <WORKFLOW_ID> \
  --from "2026-09-01" \
  --to "2026-09-30" \
  --format jsonl \
  --output workflow-runs.jsonl

JSON / JSONL should probably be the primary export format rather than CSV, because workflow nodes are heterogeneous and often contain nested objects.

CSV could optionally be provided for run-level metadata:

run_id
workflow_id
status
started_at
finished_at
duration_ms
failed_node

while the complete execution information remains available as structured JSON.

Important requirement: preserve raw node data

It would be useful to provide an option such as:

--raw

or:

--include-raw-payload

so that lark-cli does not discard fields that it does not currently understand.

This is particularly important for workflow execution logs because different node types can have very different payload structures, and new workflow node types may be added by Lark over time.

Agent use case

This feature would also be particularly valuable for AI Agents.

An Agent could use execution logs to:

• Diagnose failed workflow runs
• Find the exact failed node
• Compare successful and failed executions
• Analyze HTTP request responses
• Detect performance bottlenecks
• Trace record mutations
• Analyze conditional branches
• Reconstruct the execution path
• Generate workflow debugging reports

For example:

lark-cli base workflow-runs get <RUN_ID> --json

could give an Agent enough structured context to answer:

Why did this workflow fail?

or:

Which node is responsible for most of the execution time?

without requiring the user to manually open every node in the Lark UI.

If the upstream OpenAPI is not currently available

If Base Workflow execution logs are not yet exposed through the public Lark OpenAPI, it would still be useful for lark-cli to:

1. Track this capability as an upstream dependency.
2. Clearly document that workflow execution logs are currently unavailable through public APIs.
3. Add the corresponding CLI commands once the upstream API becomes available.

Ideally, the upstream API should expose both:

Workflow Run

and:

Workflow Run Node Execution

instead of returning only a flattened execution summary.

Why this matters

For complex Base workflows, the workflow execution log is effectively the observability and debugging layer of the workflow engine.

A single flat log row is insufficient because an execution is a tree / graph of heterogeneous node executions.

Providing structured execution logs through lark-cli would make Base workflow debugging, auditing, monitoring and AI-assisted diagnosis significantly more practical.