Provide additional logsobservability to workflow runs (per node) (#21142)

Surfaces per-step "Logs" tabs in the workflow run side panel so users
can see what each step actually did (model + tokens + tool calls for AI,
console output for serverless functions, request/response for HTTP,
recipients/body for Email).

<img width="546" height="501" alt="ai_agent_without_websearch"
src="https://github.com/user-attachments/assets/c6ca3518-9489-4484-a570-3d0569ff3b03"
/>

## Storage

- New `stepLogs` JSONB column on the `workflowRun` workspace entity,
typed as `Record<string, WorkflowRunStepLog>` (keyed by step id).
- Schema lives in `twenty-shared`: `workflowRunStepLogSchema` with a
discriminated `details.type` union for `AI_AGENT | CODE | HTTP_REQUEST |
EMAIL` — frontends and backends consume the same Zod-inferred type.
- Field is added to existing workspaces via a workspace upgrade command
(`2-9 add-workflow-run-step-logs-field`); the standard-object metadata
declares it for new workspaces.
- Writes happen atomically per step in
`WorkflowRunStepLogWorkspaceService.setStepLog` using `jsonb_set`. That
lets concurrent steps in the same run write their own keys without
contending with the existing lock around `workflowRun.state`.
- Per-step payload is hard-capped at 256 KB; anything larger is dropped
with a `logger.warn`, so a pathological tool call can never bloat a row.
See below for more information.

## How logs are produced

**Aalmost everything was already being collected; this PR mostly
persists and renders it.**

- **AI agent** — `AgentAsyncExecutorService` already tracked token
usage, model id, native web-search count, and the AI SDK's `steps[]`. We
map those into the log via `mapAiStepsToToolCallLogs` (`searchVector`
stripped from record outputs, per-call input/output capped at 32/64 KB,
max 200 tool calls per step). The only new measurement is a wall-clock
`durationMs` taken around `executeAgent`, and we now fold native
web-search cost into the displayed `totalCostInDollars` (it was already
billed, just not shown).
- **Code / serverless function** — reuses the `console.log` output the
function runner already returns (`logsByLevel`);
`build-code-step-log.util` only repackages it.
- **HTTP request** — built from the action's existing input/output via
`build-http-request-step-log.util`. No new signals collected.
- **Email (send / draft)** — added `sanitizedHtmlBody` + `plainTextBody`
to the existing tool outputs (a small additive change), then
`build-email-step-log.util` consumes them.

No additional AI inference or external calls are made for logging — the
cost is a small CPU overhead per step plus the JSONB write.

## Security

The log surface intentionally shows whatever the workflow touched, which
made redaction and sanitization the main design concern.

- **HTTP — secrets in headers**: existing `SENSITIVE_HEADER_NAMES` set
(Authorization, Cookie, …) replaced with `[redacted]` in both request
and response.
- **HTTP — secrets in URLs**: `SENSITIVE_URL_PARAM_NAMES` (e.g.
`api_key`, `token`, `access_token`) replaced in the query string via
`URL`-based parsing.
- **HTTP — secrets in bodies**: `SENSITIVE_BODY_KEY_REGEX` deep-walks
JSON request/response bodies (object input or stringified JSON) and
redacts matching keys. Applied to the `error` field too, since
transport-layer errors sometimes embed structured payloads.
- **Email — XSS risk in body preview**: tool outputs now expose a
server-side `sanitizedHtmlBody`; the log builder prefers it over the raw
user-authored `input.body`, with `plainTextBody` as a second fallback.
The original raw body is only used if sanitization didn't happen (e.g.
tool failed before composing).
- **AI — internal/noisy data**: `searchVector` (Postgres tsvector
strings) is stripped from record outputs returned by Twenty tools to
avoid leaking internal full-text-search payloads.
- **DB bloat / runaway agents**: 256 KB per-step cap + 32 KB / 64 KB
per-tool-call input/output cap + 200 tool calls per step.

<img width="547" height="307" alt="logic_function"
src="https://github.com/user-attachments/assets/dd4a3d16-67f2-434b-95b3-bdcaf9ed053d"
/>

## More details on Log size & truncation

Logs are stored in `workflowRun.stepLogs` (JSONB), keyed by `stepId`.

### Per-step cap

Each step's log is hard-capped at **256 KB** (`MAX_STEP_LOG_BYTES` in
`WorkflowRunStepLogWorkspaceService.setStepLog`).

For ~99% of workflows this is roomy — typical real-world sizes:
- Code / serverless function: 1–20 KB
- HTTP request: 5–70 KB
- Email: 5–30 KB
- AI agent (a handful of tool calls): 5–50 KB

### Two layers of bounding

1. **Per-field truncation** in each builder (before writing):
   - **Code**: ≤ 500 entries, ≤ 4 KB per message, ≤ 8 KB stack trace
   - **HTTP**: ≤ 32 KB per body (request + response), UTF-8 byte-aware
   - **Email**: ≤ 8 KB body preview, UTF-8 byte-aware
- **AI agent**: ≤ 32 KB tool input, ≤ 64 KB tool output, ≤ 200 tool
calls/step

2. **Global per-step safety net** at write time: if the assembled
`stepLog` still exceeds 256 KB, the write is **dropped entirely** with a
`logger.warn`. The workflow itself keeps running unaffected.

### What this means in practice

- **Safe**: workflow execution, step results, downstream steps — never
blocked by log size.
- **Safe**: iterators (each iteration overwrites the previous log for
that `stepId`, so they can't accumulate).
- **Safe**: step retries (same `stepId` is overwritten, not appended).
- **Possible**: an AI agent step with many large tool outputs (e.g., 50+
heavy `web_search` calls) can exceed 256 KB → the **entire** step's log
is dropped, side panel shows "No logs were recorded for this step". The
user has no explicit signal that the log was dropped due to size (only
server-side warn).
- **Possible** (theoretical): a workflow with hundreds of distinct steps
could push the row toward Postgres's internal ~256 MB jsonb limit.
Beyond that, individual `jsonb_set` writes would error and be swallowed
by the action's try/catch — workflow still completes.

### Possible future hardening (not in this PR)

- Replace "drop entire log" with a stub that preserves the summary card
(cost, duration, status) and marks `truncated.reason = 'size_cap'`.
- Surface size-drops in the UI (similar to the existing
`<StyledTruncatedNotice>`).
- Emit a metric so dropped logs are observable in dashboards.

packages/twenty-server/src/engine/core-modules/application-logs/utils/parse-application-log-lines.spec.ts

@@ -122,4 +122,24 @@ describe('parseApplicationLogLines', () => {
       },
     ]);
   });
+
+  it('strips ANSI color escapes from structured messages (chalk-style)', () => {
+    const raw = '2024-01-01T00:00:00.000Z INFO \u001B[33m4 \u001B[39m';
+
+    expect(parseApplicationLogLines(raw)).toEqual([
+      {
+        timestamp: new Date('2024-01-01T00:00:00.000Z'),
+        level: 'INFO',
+        message: '4 ',
+      },
+    ]);
+  });
+
+  it('strips ANSI color escapes from unstructured lines too', () => {
+    const raw = '\u001B[1;31mfatal\u001B[0m something bad';
+    const result = parseApplicationLogLines(raw);
+
+    expect(result).toHaveLength(1);
+    expect(result[0].message).toBe('fatal something bad');
+  });
 });

packages/twenty-server/src/engine/core-modules/application-logs/utils/parse-application-log-lines.ts

@@ -1,4 +1,5 @@
 import { type ParsedLogLine } from 'src/engine/core-modules/application-logs/types/parsed-log-line.type';
+import { stripAnsiEscapes } from 'src/engine/core-modules/application-logs/utils/strip-ansi-escapes.util';
 
 // Matches: 2024-01-01T00:00:00.000Z INFO some message
 const LOG_LINE_REGEX =
@@ -18,14 +19,14 @@ export const parseApplicationLogLines = (rawLogs: string): ParsedLogLine[] => {
       return {
         timestamp: new Date(match[1]),
         level: match[2],
-        message: match[3],
+        message: stripAnsiEscapes(match[3]),
       };
     }
 
     return {
       timestamp: new Date(),
       level: 'INFO',
-      message: line,
+      message: stripAnsiEscapes(line),
     };
   });
 };

packages/twenty-server/src/engine/core-modules/application-logs/utils/strip-ansi-escapes.util.spec.ts

@@ -0,0 +1,48 @@
+import { stripAnsiEscapes } from './strip-ansi-escapes.util';
+
+describe('stripAnsiEscapes', () => {
+  it('returns plain ASCII strings unchanged', () => {
+    expect(stripAnsiEscapes('hello world')).toBe('hello world');
+  });
+
+  it('strips SGR color codes from a yellow value', () => {
+    // What `console.log(chalk.yellow('4 '))` emits.
+    expect(stripAnsiEscapes('\u001B[33m4 \u001B[39m')).toBe('4 ');
+  });
+
+  it('strips compound SGR codes (bold + red, then reset)', () => {
+    expect(stripAnsiEscapes('\u001B[1;31merror\u001B[0m')).toBe('error');
+  });
+
+  it('strips 256-color and truecolor SGR sequences', () => {
+    expect(stripAnsiEscapes('\u001B[38;5;208mwarn\u001B[39m')).toBe('warn');
+    expect(stripAnsiEscapes('\u001B[38;2;0;128;255mblue\u001B[0m')).toBe(
+      'blue',
+    );
+  });
+
+  it('strips cursor-movement CSI sequences', () => {
+    expect(stripAnsiEscapes('a\u001B[2Jb\u001B[Hc')).toBe('abc');
+  });
+
+  it('strips OSC sequences (e.g. terminal hyperlinks)', () => {
+    const link =
+      '\u001B]8;;https://twenty.com\u0007Twenty\u001B]8;;\u0007 rocks';
+
+    expect(stripAnsiEscapes(link)).toBe('Twenty rocks');
+  });
+
+  it('handles mixed colored output across multiple chunks', () => {
+    const raw =
+      '\u001B[32mOK\u001B[39m \u001B[2mready\u001B[22m: \u001B[1mdone\u001B[0m';
+
+    expect(stripAnsiEscapes(raw)).toBe('OK ready: done');
+  });
+
+  it('leaves untouched the bracket text that survived a missing ESC', () => {
+    // Defensive: if the ESC byte was already stripped upstream, we should not
+    // try to "fix" the bracketed remnants (we cannot tell them apart from real
+    // user text).
+    expect(stripAnsiEscapes('[33m4 [39m')).toBe('[33m4 [39m');
+  });
+});

packages/twenty-server/src/engine/core-modules/application-logs/utils/strip-ansi-escapes.util.ts

@@ -0,0 +1,6 @@
+const ANSI_CSI_REGEX = /\u001B\[[0-?]*[ -/]*[@-~]/g;
+
+const ANSI_OSC_REGEX = /\u001B\][^\u0007\u001B]*(?:\u0007|\u001B\\)/g;
+
+export const stripAnsiEscapes = (value: string): string =>
+  value.replace(ANSI_CSI_REGEX, '').replace(ANSI_OSC_REGEX, '');

packages/twenty-server/src/engine/core-modules/feature-flag/constants/public-feature-flag.const.ts

@@ -28,6 +28,14 @@ export const PUBLIC_FEATURE_FLAGS: PublicFeatureFlag[] = [
         'Show the per-page hero illustration + video walkthrough modal on settings pages',
     },
   },
+  {
+    key: FeatureFlagKey.IS_WORKFLOW_RUN_STEP_LOGS_ENABLED,
+    metadata: {
+      label: 'Workflow Run Step Logs',
+      description:
+        'Persist and display per-step observability logs (token usage, tool calls, HTTP bodies, serverless function output) on workflow runs',
+    },
+  },
   ...(process.env.CLOUDFLARE_API_KEY
     ? [
         // {

packages/twenty-server/src/engine/core-modules/tool/tools/email-tool/draft-email-tool.ts

@@ -57,6 +57,8 @@ export class DraftEmailTool implements Tool {
           ccRecipients: data.recipients.cc,
           bccRecipients: data.recipients.bcc,
           subject: data.sanitizedSubject,
+          sanitizedHtmlBody: data.sanitizedHtmlBody,
+          plainTextBody: data.plainTextBody,
           connectedAccountId: data.connectedAccount.id,
           attachmentCount: data.attachments.length,
         },

packages/twenty-server/src/engine/core-modules/tool/tools/email-tool/send-email-tool.ts

@@ -64,6 +64,8 @@ export class SendEmailTool implements Tool {
           ccRecipients: data.recipients.cc,
           bccRecipients: data.recipients.bcc,
           subject: data.sanitizedSubject,
+          sanitizedHtmlBody: data.sanitizedHtmlBody,
+          plainTextBody: data.plainTextBody,
           connectedAccountId: data.connectedAccount.id,
           attachmentCount: data.attachments.length,
         },

packages/twenty-server/src/engine/core-modules/tool/tools/http-tool/http-tool.ts

@@ -70,6 +70,12 @@ export class HttpTool implements Tool {
           success: false,
           message: `HTTP ${method} request to ${url} failed`,
           error: error.response?.data || error.message || 'HTTP request failed',
+          status: error.response?.status,
+          statusText: error.response?.statusText,
+          headers: error.response?.headers as
+            | Record<string, string>
+            | undefined,
+          result: error.response?.data,
         };
       }