UPDATE: Browser Timeout after successfull Response to Webhook

Update for the moderator - i did not find the issue. But i found a weird warning in the development console of chrome:

The Content Security Policy (CSP) prevents the evaluation of arbitrary strings as JavaScript to make it more difficult for an attacker to inject unathorized code on your site.

To solve this issue, avoid using eval(), new Function(), setTimeout([string], ...) and setInterval([string], ...) for evaluating strings.

If you absolutely must: you can enable string evaluation by adding unsafe-eval as an allowed source in a script-src directive.

:warning: Allowing string evaluation comes at the risk of inline script injection.

Maybe the “Webhook Response” uses some not allowed JS-Functions?

Original Post:

I built a worflow with a webhook and an wait-webhook. It completes successfully, but the browser calling the first (trigger)-webhook never gets a response.

This is the last node and it’s output.

Background: I’m calling an endpoint, that starts a task on my phone (get geolocation) and returns an url to google maps. The redirect to this google.maps-url never reaches the browser originally calling the triggering webhook.

Any idea?

Here the workflow:

Maybe it has something to do with hosting behind a cloudflare tunnel?


(although cloudflare is really very reliable normally and the webhook-response2webhook test workflow without a wait between works flawlessly)

It also doesn’t work, if I change the redirect to a “just text” response - the calling browser gets the timeout.

  • n8n version: 1.59.4
  • Database (default: SQLite): ?? docker n8n:latest
  • n8n EXECUTIONS_PROCESS setting (default: own, main): ??docker
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Hey @ArchonMegalon,

I suspect what is happening is the issue is where you are using respond to webhook for both the webhook and the wait node so it may not be able to work out which one to reply to.

Looking at the workflow in a bit more detail it could be the change to the resume url causing the issue but to be honest I don’t know why you are making this change, If you set the WEBHOOK_URL env option the resumeUrl will use the correct domain.

When using that URL in the http request node n8n may not follow the redirect as the request isn’t made using a browser so the flow may just stop there and never actually finish.

It looks like there are a few things here, I would start by setting the config then testing the http request node on it’s own to make sure it redirects as you are expecting it and take it from there.

Hi!

Thank you for your insight. I have reworked my workflow.

The wait-node now returns immideatly. I also set up a test-webhook, that works (it redirects to google.com).

It is still the same behaviour. If I call the location-webhook, the browser does not get an answer.

No one? Any idea?

Hey @ArchonMegalon,

When you did a test on the http request node did it return to the URL you were expecting?

Yes. The Test-Webhook in this workflow works.

I trimmed it down to the essential parts:

If you trigger the “doesn’t work”-Webhook, of course you need to look at the exections and get the Url to call in another browser window. The workflow completes, but the original browser instance never gets the redirect. It is definitly a bug and only happens, when the wait-node is between the webhook and the response to webhook-node.

In the published workflow I grew tiered of calling the other url for the wait-node, so i just set the timeout to 10 second. :wink:

PS: Yes, the original http-request node in my old workflow did return what i was expecting. But that is another service (tasker for android) and has nothing to do with this problem (i think).