Summary

• FixescheckExists() in bothGitlabTrigger.node.ts andGithubTrigger.node.ts to fall back to URL-based webhook matching when the stored webhook ID becomes stale
• When the stored ID returns 404, the method now lists all repository webhooks and matches by the n8n webhook URL before giving up
• Adds tests for the new fallback behavior inGithubTrigger.node.test.ts

The problem

When publishing a workflow,checkExists() only checks if the storedwebhookData.webhookId exists on the platform. If that ID becomes stale (after workflow import, node copy, or database reset), the check returnsfalse andcreate() adds a new webhook — creating a duplicate on every publish.

The fix

Both trigger nodes now follow this strategy incheckExists():

1. Fast path: Try the stored webhook ID (existing behavior, no extra API call)
2. Fallback: If stored ID returns 404, list all webhooks for the repo and match by URL
3. Recovery: If a URL match is found, update the stored ID so future checks use the fast path

This is the same pattern GitHub'screate() method already uses in its 422 error handler — moved tocheckExists() where it prevents the problem instead of recovering from it.

Fixes#25381

Test plan

• Updated existingcheckExists test to includegetNodeWebhookUrl mock
• Added test: returns true when stored webhook ID exists (fast path)
• Added test: falls back to URL matching when stored ID returns 404
• Added test: returns false when stored ID is 404 and no URL match
• Added test: finds webhook by URL when no stored ID exists
• Added test: returns false when no stored ID and no URL match
• Manual testing with GitLab/GitHub webhook trigger workflows