Why does clicking the Wait node's resume URL restart the workflow in n8n?

Below is some guidance on troubleshooting this behavior with the Wait node’s resume URL:

1. Ensure the Resume URL Is Only Triggered Once

When you click on the resume URL (e.g. using the {{ $execution.resumeUrl }}?answer=go link), that URL is unique to the waiting execution. If the link is triggered more than once or by a separate process, it can cause a new execution to start rather than simply resuming the waiting execution. Double-check that the URL isn’t being re-clicked or inadvertently re-invoked (for example by bots or page refreshes).

2. Verify the Wait Node Configuration

Make sure that the Wait node is configured properly for the “On Webhook Call” resume style. Check the following settings:

• Authentication: Ensure that if you’re using any authentication (e.g. Basic Auth, Header Auth, or JWT), the incoming call to the resume URL is correctly authenticated.
• HTTP Method: Confirm that the webhook call’s HTTP method (GET, POST, etc.) matches what the Wait node expects.
• Limit Wait Time: Verify if a limit is set that could prematurely resume or reset the Wait node.

3. Check the Execution Process Flow

Since the resume URL is generated at run‑time and can only resume the specific execution context of the Wait node, ensure that the node sending out or exposing the URL is in the same workflow execution as the Wait node. If the URL is generated in one part but used in a different execution, it may not tie back to the original wait and start a new one.

4. Test With a Minimal Example

To narrow down the issues, try creating a minimal workflow that:

• Uses a Wait node configured to resume on webhook call.
• Sends the generated $execution.resumeUrl to a test endpoint.
• Logs when the resume URL is called.

This can help determine if the behavior is coming from:

• The link itself (and how often it is invoked)
• The settings in the Wait node
• Or an external factor (such as multiple calls or misconfiguration).

5. Monitor for Duplicate Triggers

Sometimes, if browsers or external services (like link previewers or crawlers) call the link, it can trigger a new execution. Check if extra parameters (like your query parameter "?answer=go") are necessary or if they might affect matching of the resume URL on the server side. If needed, consider using the “Ignore Bots” option provided in the Wait node settings.

Summary

The Wait node’s resume functionality depends on a one‑time, correctly matched webhook call. In your case, a new execution is being started (leading to the workflow always starting from the beginning) likely because the resume URL is being triggered more than once or being called outside of the intended execution context. Verifying your node settings and ensuring the link is only used for its intended, single resume action should help resolve the issue.

Try these steps and see if any of the adjustments prevent the workflow from restarting instead of resuming.

Below is some guidance to help diagnose and resolve this behavior:

1. Verify the Resume URL

The Wait node generates a unique resume URL during execution (via the $execution.resumeUrl variable) that must be invoked exactly as generated. When you append your own query parameters (e.g. ?answer=go), it may cause the resume mechanism not to match the URL stored for resuming. Try using the URL exactly as provided without extra modifications. If you need to pass additional data, consider sending it in the request body or using alternative methods (for example, another node to capture additional parameters) instead of modifying the resume URL.

2. Check the Node’s Resume Condition Setup

Confirm that your Wait node is configured correctly under the On Webhook Call resume option. Some things to double-check include:

• HTTP Method: Ensure that the method used to call the resume URL matches the one expected by the node.
• Authentication: If you have any authentication enabled for resume-webhook calls, make sure your call meets these settings.
• No Extra Parameters: The resume mechanism expects the exact URL that was generated. Passing extra query parameters may cause unexpected behavior.

3. Verify that No New Execution Starts

If clicking the link results in the workflow starting from the beginning, it is likely that the resume URL is being treated as a new workflow trigger rather than resuming an existing paused execution. Ensure that the URL you’re using for resumption is the one generated during the initial Pause by the Wait node.

4. Testing and Debugging

• Test the Exact URL: Try copying the generated URL from the Wait node output (or from debug logs) and calling it directly in your browser without any modifications.
• Inspect the Network Call: Use browser developer tools or a tool like cURL to see what is actually sent to n8n. Confirm that you’re sending a GET (or the expected HTTP method) without additional parameters.
• Review Logs: Check the logs to see if the request reaches the node as expected or if a new execution is being started.

Example cURL Request

Assuming that the resume URL generated is something like https://your.n8n.instance/webhook/12345, you can test it by running:

BASHCopied
curl -X GET https://your.n8n.instance/webhook/12345

Make sure not to append any extra parameters there.

Summary

It appears that by appending your custom ?answer=go parameter to the resume URL, n8n may not be recognizing the call as the proper resume trigger. Use the exact resume URL or consider handling your extra data in a different way to avoid the workflow restarting from the beginning.

Try these steps and adjust your workflow accordingly. Let me know if you need more details on any of these points!