Wait-for node does not wait

Questions
1

Describe the problem/error/question

This might be related to Wait Node not executing After Time Interval , but our issue has other symptoms. Our Wait-for nodes do not wait. Or rather, they wait for anywhere between 1 to 60 seconds as far as I can test, while it’s set to 15 minutes.

Observation

In one of our flows, there is a wait for webhook call node with a timeout of 15 minutes, and I started noticing this flow continuing without callback and almost immediately after starting. I think this started happening after we updated to 1.25.1 (from 1.20)

Recreation

Creating the simplest of flows as seen below, I could confirm the Wait node is not waiting for 15 minutes, it’s just going almost immediately.

This happens both in test mode (starting the flow manually) as in production (replacing the manual start with a webhook trigger).

Please let me know if you need more information :slight_smile:

What is the error message (if any)?

N/A

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 1.25.1
  • Database (default: SQLite): Postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): not defined explicitly (executions_mode is queue)
  • Running n8n via (Docker, npm, n8n cloud, desktop app): kubernetes with postgres and redis
  • Operating system: Google GKE (the definitive OS is unknown a.t.m. but we can find it out if relevant)
  • GENERIC_TIMEZONE=Europe/Amsterdam
2

Hey @Djennez,

What timezone do you have n8n set to?

3

Heya @Jon , It is set to GENERIC_TIMEZONE=Europe/Amsterdam (added to OP as well).

1 Like
4

Hey @Djennez,

Do you also have the TZ env option set?

5

These are all the variables in our env file (censored). No TZ variable.

DB_TYPE=postgresdb
DB_POSTGRESDB_DATABASE=***
DB_POSTGRESDB_HOST=***
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=***
GENERIC_TIMEZONE=Europe/Amsterdam
N8N_DIAGNOSTICS_ENABLED=false
N8N_VERSION_NOTIFICATIONS_ENABLED=false
N8N_HOST=***
WEBHOOK_URL=https://***/
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=730
6

Can you try adding TZ and see if that helps? It would need the same value as the timezone.

7

We added TZ=Europe/Amsterdam to the environment (and updated to 1.26.0 as well). Unfortunately no change in the issues.

Maybe this can help; these are the execution times of this simplified workflow. I tried varying the time to wait in the wait node between 15 and 30 minutes, but that does not seem to have influenced these execution times (these include overhead as well, so they’re not too exact).

image

8

Hey @Djennez,

I suspect this is related to the other issue which has not been fixed yet.

9

Anything we can provide to help?

I created a small flow that would output some testdata to see if I could find any common denominators. So far I can only find that, regardless of the input, it will never wait more than 60 seconds.

Some sample data:

Time1: 2024-02-07T14:42:54.073+01:00
Time2: 2024-02-07T14:43:12.175+01:00
Time diff in seconds: 18.10199999809265
Random metric: minutes
Random number: 17

Time1: 2024-02-07T14:43:12.495+01:00
Time2: 2024-02-07T14:44:12.221+01:00
Time diff in seconds: 59.7260000705719
Random metric: seconds
Random number: 66

Time1: 2024-02-07T14:44:12.496+01:00
Time2: 2024-02-07T14:45:12.184+01:00
Time diff in seconds: 59.687999963760376
Random metric: seconds
Random number: 92

Time1: 2024-02-07T14:45:12.397+01:00
Time2: 2024-02-07T14:46:12.189+01:00
Time diff in seconds: 59.79199981689453
Random metric: seconds
Random number: 112

Time1: 2024-02-07T14:46:12.401+01:00
Time2: 2024-02-07T14:47:12.205+01:00
Time diff in seconds: 59.80399990081787
Random metric: seconds
Random number: 107

Time1: 2024-02-07T15:07:36.155+01:00
Time2: 2024-02-07T15:08:12.270+01:00
Time diff in seconds: 36.11500000953674
Random metric: seconds
Random number: 95

Time1: 2024-02-07T15:15:32.525+01:00
Time2: 2024-02-07T15:15:39.531+01:00
Time diff in seconds: 7.005999803543091
Random metric: seconds
Random number: 7

Time1: 2024-02-07T15:15:34.209+01:00
Time2: 2024-02-07T15:15:42.215+01:00
Time diff in seconds: 8.00599980354309
Random metric: seconds
Random number: 8

Time1: 2024-02-07T15:15:33.267+01:00
Time2: 2024-02-07T15:16:06.312+01:00
Time diff in seconds: 33.045000076293945
Random metric: seconds
Random number: 33

Time1: 2024-02-07T15:15:31.225+01:00
Time2: 2024-02-07T15:16:12.340+01:00
Time diff in seconds: 41.11500000953674
Random metric: minutes
Random number: 60

Time1: 2024-02-07T15:17:15.688+01:00
Time2: 2024-02-07T15:17:41.698+01:00
Time diff in seconds: 26.009999990463257
Random metric: seconds
Random number: 26

Time1: 2024-02-07T15:17:13.238+01:00
Time2: 2024-02-07T15:18:12.363+01:00
Time diff in seconds: 59.125
Random metric: seconds
Random number: 92

Time1: 2024-02-07T15:17:13.833+01:00
Time2: 2024-02-07T15:18:12.399+01:00
Time diff in seconds: 58.56599998474121
Random metric: minutes
Random number: 49

Some runs would not even finish though.

10

Hmmm, ok, some do pass the 60 seconds mark. But it’s still not correct.

Time1: 2024-02-07T15:17:14.513+01:00
Time2: 2024-02-07T15:34:14.571+01:00
Time diff in seconds: 1020.058000087738
Random metric: minutes
Random number: 77

Time1: 2024-02-07T15:15:03.040+01:00
Time2: 2024-02-07T16:00:03.699+01:00
Time diff in seconds: 2700.6589999198914
Random metric: minutes
Random number: 105
11

Hey @Djennez,

It is likely to happen with anything over 64 seconds that gets saved to the database to be picked up later.

12

Hmmm ok, that’s unfortunate. Any simple workarounds or an indication for a fix? I guess we could just loop a 1 minute wait 15 times :sweat_smile:

13

Hey @Djennez,

I think you can set the timezone to UTC and that will do the job but the fix is in progress below

1 Like
14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.