Workflow Activates & Succeeds but Empty Response Body & Execution Details Won't Load (v1.90.2, Docker, Postgres)

Questions
1

Hello n8n community.
I have only started using n8n a month ago and so far it has been fine. However, for the last two days I have been trying to solve the following:

My Setup:

  • n8n Version: 1.91.2 (Updated from releases, 1.86.1, 1.90.2 issue persists)
  • Hosting: Self-hosted via Docker Compose on Linode (Akamai Cloud)
  • OS: Ubuntu 24.04 LTS
  • Reverse Proxy: Caddy (Handles HTTPS, proxies to n8n on internal port 5678)
  • Workflow Database: PostgreSQL 16 (Running in separate Docker container postgres_tm)
  • n8n Execution Data: Default (Presumably SQLite within the persistent /home/node/.n8n volume n8n_data)
  • Environment: NODE_FUNCTION_ALLOW_BUILTIN=crypto is set for the n8n service in docker-compose.yml, stack fully restarted after adding.

Workflow Goal & Structure (TM API - Segments POST):

The goal is to create a POST API endpoint (/api/v1/segments) that:

  1. Receives a JSON body: { "language_code": "...", "content": "..." } (via Webhook node, Auth: None, Response: responseNode).
  2. Calculates SHA256 hash of content using require('crypto') (via Code node).
  3. Checks if hash exists in translation_segments table (via Postgres node, Execute Query, SELECT ... WHERE content_hash = $1, parameter set via Options->Query Parameters).
  4. Uses an IF node to branch based on whether the SELECT returned rows ($node["Postgres"].json.length > 0).
  5. False Path (New Segment): Inserts the new segment (via Postgres1 node, Execute Query, INSERT ... VALUES ($1, $2, $3) RETURNING segment_id, parameters $1,$2,$3 set via Options->Query Parameters using an array [...] referencing Webhook and Code nodes). Then goes to Respond to Webhook1.
  6. True Path (Existing Segment): Goes directly to Respond to Webhook.
  7. Response Nodes (Respond to Webhook / Respond to Webhook1): Both are configured with:
  • Respond With: JSON
  • Response Body (Expression Mode): { "segment_id": {{$node["NodeName"].json[0].segment_id}} } (targeting Postgres for true path, Postgres1 for false path respectively).
  • Response Code: 200 (true path) or 201 (false path), set via Options.
  • No JWT credential is selected or required by the UI in this configuration on v1.90.2.

The Problem (on v1.90.2):

  1. The workflow configured as above Saves and Activates successfully.
  2. Sending POST requests to the Production URL (https://[...]/webhook/api/v1/segments) using external tools (PowerShell Invoke-RestMethod, also tried curl equivalent) results in no tool-side errors (implying HTTP 200/201 status is received).
  3. However, the tool receives NO response body. The output is empty.
  4. Checking the Executions List in the n8n UI shows these runs were triggered and completed with a status of “Succeeded”.
  5. Trying to view the details of any of these “Succeeded” executions fails – the detail panel shows a loading spinner indefinitely and never loads.

Troubleshooting Already Performed:

  • Confirmed crypto module works via NODE_FUNCTION_ALLOW_BUILTIN and testing Code node in isolation.
  • Confirmed correct PostgreSQL parameterized query setup via Options → Query Parameters (using single value for SELECT, array for INSERT). DB Credentials test successfully.
  • Tried alternative Respond to Webhook configurations:
    • Using intermediate Set nodes + Respond With: First Incoming Item (This also allowed activation but still resulted in an empty response body).
    • Using Respond With: Text + direct expression {{ $node... }} (This also allowed activation but still resulted in an empty response body).
  • Cloned the workflow (did not resolve the issue).
  • Checked n8n logs (debug level, following with -f) during activation attempts and during production runs – no specific errors related to response sending or execution finalization were observed, just the standard execution flow messages ending in success/finalized.
  • Checked server resources (CPU/RAM/IO) – no bottlenecks found.
  • Checked SQLite DB integrity (PRAGMA integrity_check) in a previous session - was okay.
  • Verified correct Production URL (no port) used for testing.

Question:

Why would this workflow activate and log executions as “Succeeded” on v1.90.2, yet consistently fail to return the response body AND fail to load the execution details view? Is this a known issue, perhaps related to Postgres interaction (even though just reading/writing basic data), execution logging/serialization bugs, or async handling in the Respond to Webhook node that persists in v1.90.2? What further diagnostic steps could pinpoint why the response isn’t being sent and the details aren’t loading, short of updating n8n again?

I can provide the workflow JSON if requested.

I hope someone can provide some guidance…

2

Hello again everyone,

Thank you for your time in looking at my issue. I wanted to provide a detailed update on further troubleshooting and the current status:

1. Upgraded to n8n v1.91.3: I have upgraded my self-hosted Docker instance to the latest version 1.91.3 (previously tested on 1.91.2, 1.90.2, and initially 1.86.1). Unfortunately, the core problems persist on v1.91.3.

2. “TM API - Segments POST copy” Workflow (Main Problematic Workflow):

  • Empty Response Body: This workflow (designed to add/find text segments in a PostgreSQL DB) still returns an empty response body to the client when tested with PowerShell’s Invoke-RestMethod. We’ve confirmed via Write-Host in PowerShell that a correctly formatted JSON payload is being sent by the client. The server responds with Content-Type: application/json but the body itself is empty.
  • Execution Details Fail to Load: The n8n UI still fails to load execution details for this workflow (shows a loading spinner indefinitely). Executions are consistently logged as “Succeeded”.

3. Comparative Test with a Simpler Workflow (“Test Crypto Code”):

  • To help isolate the issue, I tested another active workflow (“Test Crypto Code”) with a simpler structure: Webhook (POST /webhook/test-code) -> Code node (calculates SHA256 hash of input 'content') -> Respond to Webhook node.
  • This “Test Crypto Code” workflow successfully returns a JSON body to the client (e.g., { "hash": "calculated_hash_value" }).
  • Implication: This strongly suggests that the basic n8n response mechanism and my Caddy reverse proxy setup are capable of returning response bodies correctly. The empty response body issue seems localized to the more complex “TM API - Segments POST copy” workflow, possibly related to its PostgreSQL interactions, IF node logic, or internal data flow leading to the Respond to Webhook nodes.

4. Execution Detail Loading Issue is System-Wide:

  • Critically, even for the “Test Crypto Code” workflow (which does return a response body successfully), the n8n UI still fails to load its execution details. It shows the same indefinite loading spinner.
  • Implication: This indicates that the inability to view execution details is a more fundamental, system-wide problem in my n8n v1.91.3 instance, affecting multiple (if not all) workflows, regardless of whether they successfully send a response body. This severely hampers any debugging efforts.

Summary of Current State (n8n v1.91.3):

  • Problem 1 (Specific to TM API Workflow): Empty response body despite “Succeeded” execution status.
  • Problem 2 (System-Wide): Inability to load execution details for any tested workflow in the n8n UI (spinner shown).

Both of these issues are critical blockers. The system-wide failure to load execution details is particularly concerning as it prevents inspection of any workflow’s behavior or data flow.

Environment Recap (Consistent across versions):

  • n8n Version: 1.91.3 (current)
  • Hosting: Self-hosted via Docker Compose on Linode (Ubuntu 24.04 LTS)
  • Reverse Proxy: Caddy (Handles HTTPS, proxies to n8n on internal port 5678)
  • Workflow Database (for TM API): PostgreSQL 16 (separate Docker container postgres_tm)
  • n8n Execution Data Storage: Default SQLite (within /home/node/.n8n in the n8n_data Docker volume)
  • Key Environment Variable: NODE_FUNCTION_ALLOW_BUILTIN=crypto is set for the n8n service in docker-compose.yml.

My original post (from 4 days ago) contains more details on the TM API workflow structure and initial troubleshooting.

Given these persistent and now further clarified issues on the latest version, I’m increasingly suspecting there might be a deeper bug or a critical misconfiguration in how n8n handles either response finalization for certain complex workflows or, more broadly, how it records/retrieves execution data for the UI.

Any insights or further diagnostic suggestions would be greatly appreciated, especially regarding the system-wide failure to load execution details.

Thank you for your help!

3

Problem solved:
Many users might be using n8n behind a reverse proxy like Caddy and might not realize that a standard security header like X-Frame-Options "DENY" could interfere with the n8n UI itself if it uses iframes internally. Sharing that X-Frame-Options "SAMEORIGIN" resolved it for you could save others a lot of time.