-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(core): Implement inter-main communication for test webhooks in multi-main setup #8267
feat(core): Implement inter-main communication for test webhooks in multi-main setup #8267
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally this file needs refactoring and cleanup, hopefully soon. Only added to it to avoid increasing the scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
2 flaky tests on run #3734 ↗︎
Details:
24-ndv-paired-item.cy.ts • 1 flaky test
29-templates.cy.ts • 1 flaky test
Review all test suite changes for PR #8267 ↗︎ |
✅ All Cypress E2E specs passed |
Got released with |
Summary
In single-main setup, the main process keeps the frontend informed of the real-time state of the execution via hooks that push events using websockets or server-sent events. At the end of a test webhook execution, the main process also cleans up test webhooks, i.e. clears the 2-minute timeout, deregisters all test webhooks from the cache hash, and deletes them from the third-party service.
In multi-main setup, it may happen that the user's browser is connected to the main process that created the webhook, but the webhook call then arrives at a different main process. In this case events are not being informed to the frontend that the creator process is connected to, and cleanup is not happening in the creator process either.
To address this, we implement inter-main communication. The webhook-handling process does not push to its frontend - rather, the webhook-handling process sends a series of events into the command channel that all main instances are listening to. On receiving an event via this channel, the main process, if it has the relevant session ID, reacts by pushing the event to the FE.
Additionally, we set up a new event for a successful test webhook execution, and following the same procedure we instruct the original process to clear the webhooks after execution. And as a safeguard if the creator process crashes, we set a TTL on the test webhook registration hash in the cache - this TTL is extended on each new registration.
Diagram
How to test
Expectations:
http://localhost:5679
, set up a test webhook, run it, and call it athttp://localhost:5679/webhook-test/<path>
. The webhook call should land via ngrok on the first main, which should handle it successfully, relaying execution lifecycle events to the second main, and clearing test webhooks on success.http://localhost:5678
, set up a test webhook, run it, and call it athttp://localhost:5678/webhook-test/<path>
. The webhook call should land on the first main, which should handle it successfully and clear test webhooks, without going through inter-main communication.Story
https://linear.app/n8n/issue/PAY-1189