feat(integrations): show webhook script compilation status

[goncaloremelhe]

Proposed changes

The Webhook Integration Editor now clearly informs admins when a webhook script compiles successfully after saving.

• Incoming + Outgoing webhook forms show an inline success hint (“Script compiled successfully.”) when scriptEnabled is on and the server returns scriptCompiled (and no scriptError).
• Adds a i18n string for the success hint.

Issue

Closes #40094

Steps to test or reproduce

1. Go to Administration → Integrations.
2. Create or edit an Incoming WebHook Integration.
   • Enable Script Enabled.
   • Paste a valid script (no syntax errors) and save.
   • Verify the Script field shows: “Script compiled successfully.”
3. Edit the same incoming integration again:
   • Introduce a syntax error and save.
   • Verify an inline error appears (e.g., SyntaxError: ...) and the success hint is not shown.
4. Repeat steps 2–3 for an Outgoing WebHook Integration.

Further comments

Script compilation already happens server-side and is persisted as scriptCompiled or scriptError; this PR makes that result visible in the editor to reduce uncertainty after saving.

Summary by CodeRabbit

Release Notes

• New Features

  • Script compilation feedback now displays in webhook configuration forms, showing success messages and detailed error information when scripts compile or fail.

• Chores

  • Added translation support and removed internal development comments.

[dionisio-bot]

Looks like this PR is not ready to merge, because of the following issues:

• This PR is missing the 'stat: QA assured' label
• This PR is missing the required milestone or project

Please fix the issues and try again

If you have any trouble, please check the PR guidelines

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b299e08c-59b7-4703-a08d-c02d7a4c5916

📥 Commits

Reviewing files that changed from the base of the PR and between c0c8301 and 07096ec.

📒 Files selected for processing (7)

• apps/meteor/app/integrations/server/lib/validateOutgoingIntegration.ts
• apps/meteor/app/integrations/server/methods/incoming/addIncomingIntegration.ts
• apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts
• apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx
• apps/meteor/client/views/admin/integrations/outgoing/EditOutgoingWebhook.tsx
• apps/meteor/client/views/admin/integrations/outgoing/OutgoingWebhookForm.tsx
• packages/i18n/src/locales/en.i18n.json

💤 Files with no reviewable changes (3)

• apps/meteor/app/integrations/server/methods/incoming/addIncomingIntegration.ts
• apps/meteor/app/integrations/server/lib/validateOutgoingIntegration.ts
• apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts

📜 Recent review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: cubic · AI code reviewer

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{ts,tsx,js}

📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)

**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation

Files:

• apps/meteor/client/views/admin/integrations/outgoing/EditOutgoingWebhook.tsx
• apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx
• apps/meteor/client/views/admin/integrations/outgoing/OutgoingWebhookForm.tsx

🧠 Learnings (7)

📚 Learning: 2026-03-20T13:51:23.302Z

Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 39553
File: apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts:179-181
Timestamp: 2026-03-20T13:51:23.302Z
Learning: In `apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts`, the truthiness guards `...(integration.avatar && { avatar })`, `...(integration.emoji && { emoji })`, `...(integration.alias && { alias })`, and `...(integration.script && { script })` in the `$set` payload of `updateIncomingIntegration` are intentional. Empty-string values for these fields should NOT overwrite the stored value — only truthy values are persisted. Do not flag these as bugs preventing explicit clears.

Applied to files:

• apps/meteor/client/views/admin/integrations/outgoing/EditOutgoingWebhook.tsx
• apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx
• apps/meteor/client/views/admin/integrations/outgoing/OutgoingWebhookForm.tsx

📚 Learning: 2026-03-27T14:52:56.865Z

Learnt from: dougfabris
Repo: RocketChat/Rocket.Chat PR: 39892
File: apps/meteor/client/views/room/contextualBar/Threads/Thread.tsx:150-155
Timestamp: 2026-03-27T14:52:56.865Z
Learning: In Rocket.Chat, there are two different `ModalBackdrop` components with different prop APIs. During review, confirm the import source: (1) `rocket.chat/fuselage` `ModalBackdrop` uses `ModalBackdropProps` based on `BoxProps` (so it supports `onClick` and other Box/DOM props) and does not have an `onDismiss` prop; (2) `rocket.chat/ui-client` `ModalBackdrop` uses a narrower props interface like `{ children?: ReactNode; onDismiss?: () => void }` and handles Escape keypress and outside mouse-up, and it does not forward arbitrary DOM props such as `onClick`. Flag mismatched props (e.g., `onDismiss` passed to the fuselage component or `onClick` passed to the ui-client component) and ensure the usage matches the correct component being imported.

Applied to files:

• apps/meteor/client/views/admin/integrations/outgoing/EditOutgoingWebhook.tsx
• apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx
• apps/meteor/client/views/admin/integrations/outgoing/OutgoingWebhookForm.tsx

📚 Learning: 2026-01-17T01:51:47.764Z

Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 38219
File: packages/core-typings/src/cloud/Announcement.ts:5-6
Timestamp: 2026-01-17T01:51:47.764Z
Learning: In packages/core-typings/src/cloud/Announcement.ts, the AnnouncementSchema.createdBy field intentionally overrides IBannerSchema.createdBy (object with _id and optional username) with a string enum ['cloud', 'system'] to match existing runtime behavior. This is documented as technical debt with a FIXME comment at apps/meteor/app/cloud/server/functions/syncWorkspace/handleCommsSync.ts:53 and should not be flagged as an error until the runtime behavior is corrected.

Applied to files:

• apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx

📚 Learning: 2025-09-18T17:32:33.969Z

Learnt from: aleksandernsilva
Repo: RocketChat/Rocket.Chat PR: 36974
File: apps/meteor/client/components/Omnichannel/OutboundMessage/components/OutboundMessageWizard/forms/MessageForm/MessageForm.tsx:124-129
Timestamp: 2025-09-18T17:32:33.969Z
Learning: The ARIA mismatch issue in MessageForm's template field (where FieldError id used templateId instead of messageFormId) was addressed in PR `#36972` through refactoring the template field into a separate TemplateField component, which uses consistent templateFieldId for both aria-describedby and FieldError id.

Applied to files:

• apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx

📚 Learning: 2026-03-15T14:31:28.969Z

Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39647
File: apps/meteor/app/api/server/v1/users.ts:710-757
Timestamp: 2026-03-15T14:31:28.969Z
Learning: In RocketChat/Rocket.Chat, the `UserCreateParamsPOST` type in `apps/meteor/app/api/server/v1/users.ts` (migrated from `packages/rest-typings/src/v1/users/UserCreateParamsPOST.ts`) intentionally has `fields: string` (non-optional) and `settings?: IUserSettings` without a corresponding AJV schema entry. This is a pre-existing divergence carried over verbatim from the original rest-typings source (PR `#39647`). Do not flag this type/schema misalignment during the OpenAPI migration review — it is tracked as a separate follow-up fix.

Applied to files:

• apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx
• apps/meteor/client/views/admin/integrations/outgoing/OutgoingWebhookForm.tsx

📚 Learning: 2026-03-16T21:50:42.118Z

Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:42.118Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs, removing endpoint types and validators from `rocket.chat/rest-typings` (e.g., `UserRegisterParamsPOST`, `/v1/users.register` entry) is the *required* migration pattern per RocketChat/Rocket.Chat-Open-API#150 Rule 7 ("No More rest-typings or Manual Typings"). The endpoint type is re-exposed via a module augmentation `.d.ts` file in the consuming package (e.g., `packages/web-ui-registration/src/users-register.d.ts`). This is NOT a breaking change — the correct changeset bump for `rocket.chat/rest-typings` in this scenario is `minor`, not `major`. Do not flag this as a breaking change during OpenAPI migration reviews.

Applied to files:

• apps/meteor/client/views/admin/integrations/outgoing/OutgoingWebhookForm.tsx

📚 Learning: 2025-11-19T12:32:29.696Z

Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 37547
File: packages/i18n/src/locales/en.i18n.json:634-634
Timestamp: 2025-11-19T12:32:29.696Z
Learning: Repo: RocketChat/Rocket.Chat
Context: i18n workflow
Learning: In this repository, new translation keys should be added to packages/i18n/src/locales/en.i18n.json only; other locale files are populated via the external translation pipeline and/or fall back to English. Do not request adding the same key to all locale files in future reviews.

Applied to files:

• packages/i18n/src/locales/en.i18n.json

🔇 Additional comments (5)

packages/i18n/src/locales/en.i18n.json (1)

2671-2671: Looks good — correct i18n key and placement.

This key is well named and the copy is clear for the success-state UI.
Based on learnings: In this repository, new translation keys should be added to packages/i18n/src/locales/en.i18n.json only.

apps/meteor/client/views/admin/integrations/outgoing/EditOutgoingWebhook.tsx (1)

153-153: Prop wiring is correct for script-status rendering.

Passing webhookData into OutgoingWebhookForm cleanly enables the form-level script compilation feedback logic for existing integrations.

apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx (1)

322-331: Script compilation feedback logic looks solid.

The conditions correctly prioritize error output and only show the success hint when compilation succeeded without a scriptError.

apps/meteor/client/views/admin/integrations/outgoing/OutgoingWebhookForm.tsx (2)

1-1: Typing changes are clean and consistent.

Adding Serialized and accepting optional webhookData is the right shape for consuming persisted integration status in this form.

Also applies to: 55-55

---

421-430: Compile status rendering is correctly gated.

The new conditions properly show compile errors when present and show the success hint only when scriptCompiled is true and no error exists.

---

Walkthrough

The changes implement a feature to display UI feedback about webhook integration script compilation status. Three TODO comments are removed from the server-side integration methods, while the client-side webhook forms now conditionally render error and success messages based on script compilation state. The OutgoingWebhookForm component is updated to accept a webhookData prop, and a new translation key is added for the success message.

Changes

Cohort / File(s)	Summary
Server-side TODO cleanup apps/meteor/app/integrations/server/lib/validateOutgoingIntegration.ts, apps/meteor/app/integrations/server/methods/incoming/addIncomingIntegration.ts, apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts	Removed TODO comments related to notifying users about successful script compilation; no logic changes.
Incoming webhook form UI apps/meteor/client/views/admin/integrations/incoming/IncomingWebhookForm.tsx	Added conditional rendering of error and success feedback beneath the Script text area based on scriptError and scriptCompiled states.
Outgoing webhook form updates apps/meteor/client/views/admin/integrations/outgoing/OutgoingWebhookForm.tsx	Updated component to accept optional webhookData prop and added conditional error/success UI feedback for script compilation status matching incoming form behavior.
Outgoing webhook editor apps/meteor/client/views/admin/integrations/outgoing/EditOutgoingWebhook.tsx	Modified to pass webhookData prop to OutgoingWebhookForm component.
Internationalization packages/i18n/src/locales/en.i18n.json	Added English locale string for script compilation success message.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Suggested labels

type: feature

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: adding UI feedback to display webhook script compilation status in the integration forms.
Linked Issues check	✅ Passed	The PR successfully addresses issue #40094 by displaying compilation status feedback in both Incoming and Outgoing webhook forms when scripts compile successfully or fail.
Out of Scope Changes check	✅ Passed	All changes directly support the objective of surfacing script compilation status in the UI; no unrelated modifications were introduced outside the stated scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ 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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cubic-dev-ai]

No issues found across 7 files