# Context
Part of a CI flakiness sweep. `webhooks.integration-spec.ts` › "should
deliver webhook successfully when safe mode is disabled" intermittently
fails with `expect(receiver.receivedPayloads.length).toBe(1) ...
Received: 0` on unrelated PRs (example: run 28959576750, shard 3).
# Root cause
The test asserted delivery after a fixed 100ms sleep. Delivery actually
crosses: a fire-and-forget `EventEmitter2.emit` (the GraphQL response
returns before the job is even enqueued) → BullMQ hop 1
(`CallWebhookJobsJob`, which also recomputes the just-invalidated
`flatWebhookMaps` cache) → BullMQ hop 2 (`CallWebhookJob`) → HTTP POST
to the in-test receiver. Two Redis round trips plus a cache rebuild
routinely exceed 100ms on loaded CI runners. The global
`waitForAllJobsToFinish` only runs in `afterEach`, after the assertion.
# Fix
- Poll the receiver with the existing `expectEventually` helper (30s
deadline, 100ms interval) instead of sleeping, and give the test an
explicit 60s timeout (suite default is 20s). Worst case the test fails
slower; it can no longer fail while delivery is merely in flight.
- Bonus bug found during adversarial review of this fix: the `finally`
cleanup deleted config key `HTTP_TOOL_SAFE_MODE_ENABLED` while the test
creates `OUTBOUND_HTTP_SAFE_MODE_ENABLED`, silently leaving outbound
safe mode disabled in the DB for every suite that runs after this one.
Fixed the key.
Duplicate-delivery risk was checked: `CallWebhookJob.handle` never
throws (errors swallowed), so `retryLimit: 3` can't produce a second
payload that would break `toBe(1)`.
Test-only change, 1 file, +15/-9.
---
_Generated by [Claude
Code](https://claude.ai/code/session_01AtD2wWm3EthV6t3Hs31QyB)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22699?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Summary
- Adds SSRF (Server-Side Request Forgery) protection to webhook requests
by using the same secure axios adapter already used by HTTP workflow
actions
- Prevents webhooks from making requests to private/internal IP
addresses (10.x, 192.168.x, 172.16-31.x, 169.254.x, localhost)
- Adds specific error logging when a webhook fails due to SSRF
protection
## Context
The HTTP workflow tool (`HTTP_REQUEST` action) already had SSRF
protection via `HTTP_TOOL_SAFE_MODE_ENABLED`, but webhooks were using
`HttpService` directly without this protection. This inconsistency meant
users could potentially configure webhooks to probe internal
infrastructure.
### What's protected now:
| Feature | Before | After |
|---------|--------|-------|
| HTTP Workflow Action | Protected (secure adapter) | Protected (secure
adapter) |
| Webhooks | **Unprotected** | Protected (secure adapter) |
### The secure adapter validates:
1. Protocol must be `http:` or `https:`
2. DNS resolution of hostname
3. Resolved IP must not be in private ranges
## Test plan
- [ ] Configure a webhook with an external URL (e.g.,
`https://webhook.site`) - should work
- [ ] Configure a webhook with `http://localhost:3000` - should fail
with SSRF error in audit log
- [ ] Configure a webhook with `http://10.0.0.1/test` - should fail with
SSRF error in audit log
- [ ] Configure a webhook with a domain that resolves to a private IP -
should fail
martmull
