feat(integrations): support chatRoomFilter and chat rule types

[AndyTWF]

Summary

• Ably Chat integration rules populate chatRoomFilter (top-level on the rule, alongside source) rather than source.channelFilter. ably integrations get/list previously had no way to display this, so chat-room-sourced rules looked like they had no filter configured. integrations get/list now show a "Chat Room Filter" line when set, and include chatRoomFilter in --json output.
• integrations create/update gained a --chat-room-filter flag and chat.message as a --source-type option — but on their own these only covered the classic Reactor-style rule types (http, amqp, etc.), which turned out not to be the actual rule types Ably Chat rules use.
• Investigating against the real Control API showed that chat-sourced rules (moderation vendors, before-publish webhooks, dashboards) use a structurally different schema: invocationMode + beforePublishConfig instead of requestMode, and a source object that rejects channelFilter entirely. integrations create had no way to create any of these rule types at all. This PR adds full support for all seven: http/before-publish, hive/text-model-only, hive/dashboard, bodyguard/text-moderation, tisane/text-moderation, azure/text-moderation, and aws/lambda/before-publish. Each gets its own typed target flags (--target-api-key, --target-endpoint, --target-function-name, --threshold key=value, etc.), and invocationMode/beforePublishConfig are set automatically per rule type (only hive/dashboard runs AFTER_PUBLISH; everything else is BEFORE_PUBLISH with a configurable retry/failure policy).
• Fixed two bugs uncovered while building this: chatRoomFilter and source.channelFilter were being sent unconditionally (even as empty strings), which the Control API rejects outright for chat.message-sourced and before-publish rules — now both are only included when actually set. A modelUrl: null default was also rejected by the schema (it only accepts a string or omission) — now omitted when not provided.
• Rule/RuleData interfaces in control-api.ts updated to match: invocationMode, beforePublishConfig added, requestMode/source.channelFilter made optional.
• integrations get/list also surface invocationMode and no longer print a blank "Request Mode" line for rule types that don't have one.
• Corrected channelFilter/chatRoomFilter example and test values to valid regex syntax (e.g. chat:.*, room:.*) instead of glob-style chat:* — both fields are regexps evaluated by the Control API, not globs.

Test plan

• pnpm prepare (build + manifest)
• pnpm exec eslint . — 0 errors
• pnpm test:unit — full suite passes (2553 tests)
• pnpm test:tty — passes
• Unit tests added/updated for integrations create/get/list/update covering all seven chat rule types, required-flag validation per type, beforePublishConfig defaults/overrides, and the hive/dashboard AFTER_PUBLISH/no-beforePublishConfig exception
• e2e suite (test/e2e/integrations/integrations-e2e.test.ts) extended with a full create/get/delete lifecycle for every chat rule type, plus a fix to the existing chat-room-sourced test which used the wrong (http) rule type. Actually run against the real Control API (with E2E_ABLY_ACCESS_TOKEN/E2E_ABLY_API_KEY) this time — all 10 tests pass, including app create/teardown
• Manually verified all seven rule types create successfully via node bin/run.js integrations create ... against a real app, then cleaned up the test rules

Notes from live verification

• azure/text-moderation's target.endpoint is validated via a live DNS lookup at rule-creation time (422 on ENOTFOUND), so the e2e test uses a real resolvable hostname rather than a placeholder.
• Found (not fixed here, since it's unrelated to this feature and likely affects other ID-taking commands too): rule IDs can start with - (e.g. -MYkHg), which oclif's arg parser misreads as an unknown flag rather than a positional argument for integrations get/delete. Worked around it in the new e2e tests with a -- separator; flagging as a follow-up since it'd affect real users with an unlucky rule ID.

DX-1546

Manual testing

Run against a local build of this branch (pnpm prepare then node bin/run.js ...) — the globally installed ably CLI will be an older published version without this support.

1. Create a before-publish webhook sourced from a chat room:

   node bin/run.js integrations create --rule-type "http/before-publish" --source-type "chat.message" --chat-room-filter "room:.*" --target-url "https://example.com/webhook"
   

   Confirm the output includes Chat Room Filter: room:.* and Invocation Mode: BEFORE_PUBLISH.
2. Create a moderation rule, e.g. tisane:

   node bin/run.js integrations create --rule-type "tisane/text-moderation" --source-type "chat.message" --target-api-key "key" --threshold "profanity=1" --threshold "allegation=1" --default-language "*"
   

3. Get the rule and confirm the new fields are shown:

   node bin/run.js integrations get <ruleId>
   node bin/run.js integrations get <ruleId> --json   # confirm "chatRoomFilter"/"invocationMode"/"beforePublishConfig" are present
   

4. List rules and confirm chat rules show their filter/invocation mode, and pre-existing channel.message rules show neither:

   node bin/run.js integrations list
   node bin/run.js integrations list --json
   

5. Update a rule's chat room filter and re-verify via get:

   node bin/run.js integrations update <ruleId> --chat-room-filter "chat:.*"
   node bin/run.js integrations get <ruleId>
   

6. Delete the rule to clean up:

   node bin/run.js integrations delete <ruleId>
   

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cli-web-cli	Ready	Preview, Comment	Jul 23, 2026 6:44pm