feat: add multi-domain filters to webhooks#361
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Deploying usesend with
|
| Latest commit: |
508e3d0
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://89ab6e27.usesend.pages.dev |
| Branch Preview URL: | https://feat-webhook-domain-filter.usesend.pages.dev |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds domain-scoped webhook support by introducing Possibly related PRs
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/web/src/app/(dashboard)/webhooks/webhook-update-dialog.tsx (1)
317-395: Consider extracting domain selection into a shared component.The domain selection UI (lines 317-395) is nearly identical to the implementation in
add-webhook.tsx(lines 323-401). Consider extracting this into a reusableDomainSelectorcomponent to reduce duplication.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/web/src/app/`(dashboard)/webhooks/webhook-update-dialog.tsx around lines 317 - 395, Extract the repeated domain-selection UI into a reusable DomainSelector component and replace the inline FormField render block with it: create DomainSelector that accepts props { domains, selectedDomainIds, onChange } (or accept form field callbacks and integrate with FormField) and encapsulates the DropdownMenu, DropdownMenuTrigger/Content, DropdownMenuCheckboxItem list, the "All domains" checkbox, selectedDomainsLabel logic, and handleToggleDomain behavior; then update both webhook-update-dialog.tsx and add-webhook.tsx to use <DomainSelector .../> (wired to form.control or field.onChange) to remove duplication while preserving the existing behaviors and callbacks (FormField, DropdownMenuCheckboxItem, handleToggleDomain, selectedDomainsLabel).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/web/src/app/`(dashboard)/webhooks/webhook-update-dialog.tsx:
- Around line 317-395: Extract the repeated domain-selection UI into a reusable
DomainSelector component and replace the inline FormField render block with it:
create DomainSelector that accepts props { domains, selectedDomainIds, onChange
} (or accept form field callbacks and integrate with FormField) and encapsulates
the DropdownMenu, DropdownMenuTrigger/Content, DropdownMenuCheckboxItem list,
the "All domains" checkbox, selectedDomainsLabel logic, and handleToggleDomain
behavior; then update both webhook-update-dialog.tsx and add-webhook.tsx to use
<DomainSelector .../> (wired to form.control or field.onChange) to remove
duplication while preserving the existing behaviors and callbacks (FormField,
DropdownMenuCheckboxItem, handleToggleDomain, selectedDomainsLabel).
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
apps/web/prisma/schema.prismaapps/web/src/app/(dashboard)/webhooks/[webhookId]/webhook-info.tsxapps/web/src/app/(dashboard)/webhooks/add-webhook.tsxapps/web/src/app/(dashboard)/webhooks/webhook-update-dialog.tsxapps/web/src/server/api/routers/webhook.tsapps/web/src/server/service/domain-service.tsapps/web/src/server/service/ses-hook-parser.tsapps/web/src/server/service/webhook-service.ts
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/web/src/server/api/routers/webhook-domain-filter.trpc.test.ts (1)
77-115: Consider adding edge case tests.The current tests verify that
domainIdsis passed through correctly, which is good. For more comprehensive coverage, consider adding tests for:
- Empty
domainIds: [](global webhook behavior)- Omitted
domainIds(should remainundefinedin the service call)This would help document the expected behavior for global vs. domain-scoped webhooks.
💡 Example additional test cases
it("passes empty domainIds for global webhooks", async () => { const caller = createCaller(getContext()); await caller.create({ url: "https://example.com/webhook", eventTypes: ["email.sent"], domainIds: [], }); expect(mockWebhookService.createWebhook).toHaveBeenCalledWith( expect.objectContaining({ domainIds: [], }) ); }); it("omits domainIds when not provided", async () => { const caller = createCaller(getContext()); await caller.create({ url: "https://example.com/webhook", eventTypes: ["email.sent"], }); expect(mockWebhookService.createWebhook).toHaveBeenCalledWith( expect.objectContaining({ domainIds: undefined, }) ); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/web/src/server/api/routers/webhook-domain-filter.trpc.test.ts` around lines 77 - 115, Add two edge-case tests to the existing webhook-domain-filter.trpc.test.ts: one that calls create (via createCaller(getContext())) with domainIds: [] and asserts mockWebhookService.createWebhook was called containing domainIds: [], and another that calls create without providing domainIds and asserts the service call contains domainIds: undefined; follow the pattern used in the existing tests (use expect.objectContaining and the same caller/getContext setup) and mirror the existing assertions for update/create so the new tests reference mockWebhookService.createWebhook and createCaller/getContext.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/web/src/server/api/routers/webhook-domain-filter.trpc.test.ts`:
- Around line 77-115: Add two edge-case tests to the existing
webhook-domain-filter.trpc.test.ts: one that calls create (via
createCaller(getContext())) with domainIds: [] and asserts
mockWebhookService.createWebhook was called containing domainIds: [], and
another that calls create without providing domainIds and asserts the service
call contains domainIds: undefined; follow the pattern used in the existing
tests (use expect.objectContaining and the same caller/getContext setup) and
mirror the existing assertions for update/create so the new tests reference
mockWebhookService.createWebhook and createCaller/getContext.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/web/prisma/migrations/20260227040924_add_webhook_domain_filters/migration.sqlapps/web/src/server/api/routers/webhook-domain-filter.trpc.test.ts
There was a problem hiding this comment.
🧹 Nitpick comments (2)
apps/web/src/server/service/webhook-service.unit.test.ts (1)
120-186: LGTM! Thorough validation of domain-filtered emission.The test comprehensively verifies the query structure when a domain context is provided, including both branches of the OR condition (global webhooks and domain-specific matches).
Optional: Consider adding a test case for
{ domainId: null }to verify it behaves the same as omitting the option entirely, matching the== nullcheck in the implementation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/web/src/server/service/webhook-service.unit.test.ts` around lines 120 - 186, Add a new unit test in webhook-service.unit.test.ts (next to the existing "filters webhooks by domain when the event has a domain context" test) that calls WebhookService.emit with the same payload but options { domainId: null } and asserts that mockDb.webhook.findMany is called with the identical where clause (including the AND with the domainIds isEmpty OR has 42 behavior when applicable), and that mockDb.webhookCall.create and mockQueueAdd are invoked the same number of times with the same args; reference WebhookService.emit, mockDb.webhook.findMany, mockDb.webhookCall.create and mockQueueAdd when locating the code to mirror the existing test setup and expectations.apps/web/src/server/service/webhook-service.ts (1)
354-376: Correct domain status validation in the query.The validation ensures domains belong to the team but doesn't check the domain's
statusfield. This allows scoping webhooks to domains withPENDINGor other non-active statuses. While this behavior may be intentional, consider restricting selection to verified (SUCCESS) domains only if webhooks should only trigger for ready domains.Note: The
DomainStatusenum usesSUCCESSfor verified domains (notVERIFIED).If restricting to active domains is desired:
private static async assertDomainsBelongToTeam( domainIds: number[], teamId: number, ) { const matchingDomains = await db.domain.findMany({ where: { id: { in: domainIds, }, teamId, + status: "SUCCESS", }, select: { id: true, }, }); if (matchingDomains.length !== domainIds.length) { throw new UnsendApiError({ code: "NOT_FOUND", - message: "One or more domains were not found", + message: "One or more domains were not found or are not verified", }); } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/web/src/server/service/webhook-service.ts` around lines 354 - 376, The current assertDomainsBelongToTeam (used in webhook-service.ts) only verifies team ownership but not domain status; to restrict to verified/active domains update the db.domain.findMany query filter to include status: DomainStatus.SUCCESS (using the existing DomainStatus enum) so only domains with verified status count toward matchingDomains, and keep the existing UnsendApiError throw when counts mismatch; ensure DomainStatus is imported/available in the file before using it.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/web/src/server/service/webhook-service.ts`:
- Around line 354-376: The current assertDomainsBelongToTeam (used in
webhook-service.ts) only verifies team ownership but not domain status; to
restrict to verified/active domains update the db.domain.findMany query filter
to include status: DomainStatus.SUCCESS (using the existing DomainStatus enum)
so only domains with verified status count toward matchingDomains, and keep the
existing UnsendApiError throw when counts mismatch; ensure DomainStatus is
imported/available in the file before using it.
In `@apps/web/src/server/service/webhook-service.unit.test.ts`:
- Around line 120-186: Add a new unit test in webhook-service.unit.test.ts (next
to the existing "filters webhooks by domain when the event has a domain context"
test) that calls WebhookService.emit with the same payload but options {
domainId: null } and asserts that mockDb.webhook.findMany is called with the
identical where clause (including the AND with the domainIds isEmpty OR has 42
behavior when applicable), and that mockDb.webhookCall.create and mockQueueAdd
are invoked the same number of times with the same args; reference
WebhookService.emit, mockDb.webhook.findMany, mockDb.webhookCall.create and
mockQueueAdd when locating the code to mirror the existing test setup and
expectations.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 53cf3f4f-dfed-4be3-96c9-7210887ba03f
📒 Files selected for processing (2)
apps/web/src/server/service/webhook-service.tsapps/web/src/server/service/webhook-service.unit.test.ts
KMKoushik
force-pushed
the
feat/webhook-domain-filter
branch
from
303c368 to
efbba79
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
apps/web/src/app/(dashboard)/webhooks/webhook-update-dialog.tsx (1)
55-56: TreatdomainIdsas required in this dialog.
Webhook.domainIdsis a required field in the schema (Int[]@default([])), but the local type override makes it optional. This allows missing data to silently default to[]("All domains"), which on save will clear the webhook's domain scope instead of surfacing the integration bug. Remove the optional override.♻️ Suggested cleanup
type EditWebhookFormValues = z.infer<typeof editWebhookSchema>; -type WebhookWithDomainIds = Webhook & { domainIds?: number[] }; export function EditWebhookDialog({ webhook, open, onOpenChange, }: { - webhook: WebhookWithDomainIds; + webhook: Webhook; open: boolean; onOpenChange: (open: boolean) => void; }) { @@ defaultValues: { url: webhook.url, eventTypes: initialHasAllEvents ? [] : (webhook.eventTypes as WebhookEventType[]), - domainIds: webhook.domainIds ?? [], + domainIds: webhook.domainIds, }, }); @@ form.reset({ url: webhook.url, eventTypes: hasAllEvents ? [] : (webhook.eventTypes as WebhookEventType[]), - domainIds: webhook.domainIds ?? [], + domainIds: webhook.domainIds, });Also applies to: 71-71, 90-103, 122-122 in
webhook-update-dialog.tsxand the same pattern inwebhook-info.tsxlines 13–93.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/web/src/app/`(dashboard)/webhooks/webhook-update-dialog.tsx around lines 55 - 56, The local type override makes domainIds optional which masks missing data and can clear domain scope on save; update the WebhookWithDomainIds type to make domainIds required (change to Webhook & { domainIds: number[] }) and remove any code paths that rely on domainIds being undefined; then audit and update all usages in webhook-update-dialog (the WebhookWithDomainIds declaration and places that assume optionality) and the corresponding pattern in webhook-info (replace optional handling with required handling or explicit validation/error reporting) so missing domainIds surface as an integration bug rather than defaulting to [].
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@apps/web/prisma/migrations/20260227040924_add_webhook_domain_filters/migration.sql`:
- Line 2: The migration adds the Webhook.domainIds column but leaves it
nullable; update the migration so the "domainIds" column on table "Webhook" is
created as NOT NULL with the same default empty integer array
(ARRAY[]::INTEGER[]), or add an immediate ALTER TABLE ... ALTER COLUMN ... SET
NOT NULL after creation; ensure the SQL references the "Webhook" table and
"domainIds" column exactly and preserves the default empty array to match the
Prisma model Int[] (required) semantics.
In `@apps/web/src/app/`(dashboard)/webhooks/add-webhook.tsx:
- Around line 394-397: Update the FormDescription copy in add-webhook.tsx to
clarify that the domain filter only applies to domain-aware events (those that
include a domainId) and does not prevent team- or global-level events; use
similar wording in the edit dialog so both UIs match. Locate the FormDescription
node in this file (and the corresponding edit dialog component) and replace the
current text with a succinct message stating that leaving it blank receives all
events, while specifying a domain only filters events that carry a domainId.
---
Nitpick comments:
In `@apps/web/src/app/`(dashboard)/webhooks/webhook-update-dialog.tsx:
- Around line 55-56: The local type override makes domainIds optional which
masks missing data and can clear domain scope on save; update the
WebhookWithDomainIds type to make domainIds required (change to Webhook & {
domainIds: number[] }) and remove any code paths that rely on domainIds being
undefined; then audit and update all usages in webhook-update-dialog (the
WebhookWithDomainIds declaration and places that assume optionality) and the
corresponding pattern in webhook-info (replace optional handling with required
handling or explicit validation/error reporting) so missing domainIds surface as
an integration bug rather than defaulting to [].
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4f9adfb1-9bbb-4382-a452-966273e55060
📒 Files selected for processing (11)
apps/web/prisma/migrations/20260227040924_add_webhook_domain_filters/migration.sqlapps/web/prisma/schema.prismaapps/web/src/app/(dashboard)/webhooks/[webhookId]/webhook-info.tsxapps/web/src/app/(dashboard)/webhooks/add-webhook.tsxapps/web/src/app/(dashboard)/webhooks/webhook-update-dialog.tsxapps/web/src/server/api/routers/webhook-domain-filter.trpc.test.tsapps/web/src/server/api/routers/webhook.tsapps/web/src/server/service/domain-service.tsapps/web/src/server/service/ses-hook-parser.tsapps/web/src/server/service/webhook-service.tsapps/web/src/server/service/webhook-service.unit.test.ts
🚧 Files skipped from review as they are similar to previous changes (4)
- apps/web/prisma/schema.prisma
- apps/web/src/server/service/webhook-service.unit.test.ts
- apps/web/src/server/api/routers/webhook-domain-filter.trpc.test.ts
- apps/web/src/server/service/domain-service.ts
| @@ -0,0 +1,2 @@ | |||
| -- AlterTable | |||
| ALTER TABLE "Webhook" ADD COLUMN "domainIds" INTEGER[] DEFAULT ARRAY[]::INTEGER[]; | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Webhook model ==="
sed -n '/model Webhook/,/}/p' apps/web/prisma/schema.prisma
echo
echo "=== Migration ==="
sed -n '1,20p' apps/web/prisma/migrations/20260227040924_add_webhook_domain_filters/migration.sqlRepository: usesend/useSend
Length of output: 1825
🏁 Script executed:
cat -n apps/web/src/server/service/webhook-service.ts | head -100Repository: usesend/useSend
Length of output: 3476
🏁 Script executed:
rg "domainIds" apps/web/src/server/service/webhook-service.ts -B 2 -A 2Repository: usesend/useSend
Length of output: 1715
🏁 Script executed:
rg "isEmpty|\.has" apps/web/src/server/service/ -B 2 -A 2 --type ts --max-count 20Repository: usesend/useSend
Length of output: 5309
Add NOT NULL constraint to match the Prisma model definition.
The Prisma schema declares domainIds as a required field (Int[] without ?) with default [], but the migration allows NULL at the database level. This mismatch means if NULL ever enters the column (via raw SQL, data corruption, or other means), the filter logic using isEmpty and has would not behave as expected, potentially silencing webhooks from domain filtering.
🛠️ Suggested migration change
-ALTER TABLE "Webhook" ADD COLUMN "domainIds" INTEGER[] DEFAULT ARRAY[]::INTEGER[];
+ALTER TABLE "Webhook" ADD COLUMN "domainIds" INTEGER[] NOT NULL DEFAULT ARRAY[]::INTEGER[];📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ALTER TABLE "Webhook" ADD COLUMN "domainIds" INTEGER[] DEFAULT ARRAY[]::INTEGER[]; | |
| ALTER TABLE "Webhook" ADD COLUMN "domainIds" INTEGER[] NOT NULL DEFAULT ARRAY[]::INTEGER[]; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@apps/web/prisma/migrations/20260227040924_add_webhook_domain_filters/migration.sql`
at line 2, The migration adds the Webhook.domainIds column but leaves it
nullable; update the migration so the "domainIds" column on table "Webhook" is
created as NOT NULL with the same default empty integer array
(ARRAY[]::INTEGER[]), or add an immediate ALTER TABLE ... ALTER COLUMN ... SET
NOT NULL after creation; ensure the SQL references the "Webhook" table and
"domainIds" column exactly and preserves the default empty array to match the
Prisma model Int[] (required) semantics.
| <FormDescription> | ||
| Leave this as all domains to receive events from every | ||
| domain. | ||
| </FormDescription> |
There was a problem hiding this comment.
Clarify that this only filters domain-aware events.
The backend only narrows dispatch when the emitted event carries a domainId, so this copy currently reads stronger than the actual behavior and can surprise users when team-level events still arrive. Please mirror the same wording in the edit dialog too.
✏️ Suggested copy
- Leave this as all domains to receive events from every
- domain.
+ Leave this as all domains to receive events from every
+ domain. Domain filters apply only to events that include
+ a domain.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <FormDescription> | |
| Leave this as all domains to receive events from every | |
| domain. | |
| </FormDescription> | |
| <FormDescription> | |
| Leave this as all domains to receive events from every | |
| domain. Domain filters apply only to events that include | |
| a domain. | |
| </FormDescription> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/web/src/app/`(dashboard)/webhooks/add-webhook.tsx around lines 394 -
397, Update the FormDescription copy in add-webhook.tsx to clarify that the
domain filter only applies to domain-aware events (those that include a
domainId) and does not prevent team- or global-level events; use similar wording
in the edit dialog so both UIs match. Locate the FormDescription node in this
file (and the corresponding edit dialog component) and replace the current text
with a succinct message stating that leaving it blank receives all events, while
specifying a domain only filters events that carry a domainId.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/web/src/app/(dashboard)/webhooks/webhook-update-dialog.tsx (1)
317-395: Consider extracting a sharedDomainSelectorcomponent.The domain selection UI and logic are nearly identical between
add-webhook.tsxand this file. A shared component could reduce duplication and ensure consistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/web/src/app/`(dashboard)/webhooks/webhook-update-dialog.tsx around lines 317 - 395, Extract the duplicated domain selection UI/logic into a shared DomainSelector component: move the FormField render block that handles "domainIds" (including selectedDomainIds calculation, selectedDomainsLabel, handleToggleDomain, and the DropdownMenu with DropdownMenuCheckboxItem entries) into a new reusable DomainSelector component that accepts props { value, onChange, domains } (or integrates with react-hook-form via a controlled prop) and replace the inline FormField render in both webhook-update-dialog.tsx and add-webhook.tsx with <FormField name="domainIds" control={form.control} render={({field}) => <DomainSelector value={field.value} onChange={field.onChange} domains={domainsQuery.data} />} /> so the shared logic (selectedDomainsLabel, toggling, "All domains" checkbox behavior, and aria/text layout) lives in one place.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/web/src/app/`(dashboard)/webhooks/webhook-update-dialog.tsx:
- Around line 388-391: Update the FormDescription used in the webhook update
dialog (inside the WebhookUpdateDialog component where FormDescription is
rendered) to match the add-webhook clarification: change the text to state that
leaving it as "all domains" will receive events from every domain, but that
domain filtering only applies to events that include a domainId and team-level
events will still be delivered regardless of this setting; replace the existing
sentence in the FormDescription node accordingly to reflect that distinction.
---
Nitpick comments:
In `@apps/web/src/app/`(dashboard)/webhooks/webhook-update-dialog.tsx:
- Around line 317-395: Extract the duplicated domain selection UI/logic into a
shared DomainSelector component: move the FormField render block that handles
"domainIds" (including selectedDomainIds calculation, selectedDomainsLabel,
handleToggleDomain, and the DropdownMenu with DropdownMenuCheckboxItem entries)
into a new reusable DomainSelector component that accepts props { value,
onChange, domains } (or integrates with react-hook-form via a controlled prop)
and replace the inline FormField render in both webhook-update-dialog.tsx and
add-webhook.tsx with <FormField name="domainIds" control={form.control}
render={({field}) => <DomainSelector value={field.value}
onChange={field.onChange} domains={domainsQuery.data} />} /> so the shared logic
(selectedDomainsLabel, toggling, "All domains" checkbox behavior, and aria/text
layout) lives in one place.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fda410bb-db3b-435e-b3b6-114211ffa5e0
📒 Files selected for processing (3)
apps/web/src/app/(dashboard)/campaigns/schedule-campaign.tsxapps/web/src/app/(dashboard)/webhooks/add-webhook.tsxapps/web/src/app/(dashboard)/webhooks/webhook-update-dialog.tsx
| <FormDescription> | ||
| Leave this as all domains to receive events from every | ||
| domain. | ||
| </FormDescription> |
There was a problem hiding this comment.
Update FormDescription to match add-webhook.tsx clarification.
Per the past review comment on add-webhook.tsx, this text should clarify that domain filtering only applies to events that include a domainId. Team-level events will still be delivered regardless of this setting.
✏️ Suggested copy
<FormDescription>
- Leave this as all domains to receive events from every
- domain.
+ Leave this as all domains to receive events from every
+ domain. Domain filters apply only to events that include
+ a domain.
</FormDescription>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <FormDescription> | |
| Leave this as all domains to receive events from every | |
| domain. | |
| </FormDescription> | |
| <FormDescription> | |
| Leave this as all domains to receive events from every | |
| domain. Domain filters apply only to events that include | |
| a domain. | |
| </FormDescription> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/web/src/app/`(dashboard)/webhooks/webhook-update-dialog.tsx around lines
388 - 391, Update the FormDescription used in the webhook update dialog (inside
the WebhookUpdateDialog component where FormDescription is rendered) to match
the add-webhook clarification: change the text to state that leaving it as "all
domains" will receive events from every domain, but that domain filtering only
applies to events that include a domainId and team-level events will still be
delivered regardless of this setting; replace the existing sentence in the
FormDescription node accordingly to reflect that distinction.
1 participant
Summary
domainIds), where empty means all domains.Testing
Summary by cubic
Added multi-domain filters to webhooks so endpoints can target specific domains or all. Domain filtering applies only when a domainId is present; null or missing domain context sends events to all matching endpoints.
New Features
Migration
Written for commit 508e3d0. Summary will update on new commits.
Summary by CodeRabbit
New Features
Chores
Tests