Skip to content

fix(messaging): enable generated Slack channel config#4222

Merged
ericksoa merged 16 commits into
mainfrom
fix/4189_slack-channel-start
May 27, 2026
Merged

fix(messaging): enable generated Slack channel config#4222
ericksoa merged 16 commits into
mainfrom
fix/4189_slack-channel-start

Conversation

@chengjiew

@chengjiew chengjiew commented May 26, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Bake channels.slack.enabled: true into generated OpenClaw config when Slack is selected during onboarding.
  • Add regression coverage so Slack config generation includes the top-level enabled marker alongside the default account tokens.

Test Plan

  • npm test -- test/generate-openclaw-config.test.ts
  • npm test -- test/onboard-messaging.test.ts
  • npm test -- test/nemoclaw-start.test.ts
  • git diff --check && python3 -m py_compile scripts/generate-openclaw-config.py
  • npm run build:cli

Fixes #4189

Signed-off-by: Chengjie Wang chengjiew@nvidia.com

Summary by CodeRabbit

  • Improvements

    • Slack integration now marked explicitly enabled in generated configuration and plugin entries.
    • E2E context emission includes messaging provider when present in plan.
  • Tests

    • Updated validation and e2e tests to assert Slack enablement across config surfaces and runtime discovery.
    • Messaging suite wiring expects an additional stable assertion for Slack runtime discovery.
  • Reliability

    • Remote sandbox config reads supported when local config paths are absent.

Review Change Stack

Signed-off-by: Chengjie Wang <chengjiew@nvidia.com>
@copy-pr-bot

copy-pr-bot Bot commented May 26, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@github-actions

Copy link
Copy Markdown
Contributor

This repository limits contributors to 10 open pull requests. Please close or merge existing PRs before opening new ones.

@github-actions github-actions Bot closed this May 26, 2026
@github-actions

github-actions Bot commented May 26, 2026

Copy link
Copy Markdown
Contributor

E2E Advisor Recommendation

Required E2E: ubuntu-repo-cloud-openclaw-slack, messaging-providers-e2e
Optional E2E: openclaw-slack-pairing-e2e, ubuntu-repo-cloud-openclaw

Dispatch hint: ubuntu-repo-cloud-openclaw-slack

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

  • ubuntu-repo-cloud-openclaw-slack (medium): Primary required coverage for this PR: exercises OpenClaw onboarding with Slack enabled and runs the scenario messaging-slack suite, including the changed slack-provider-state runtime-discovery assertion against a live sandbox config.
  • messaging-providers-e2e (high): Required because the PR changes Slack provider/channel config generation and messaging provider validation. This existing job validates the credential provider, placeholder, no-secret-leak, sandbox config patching, and messaging proxy path with fake Telegram/Discord/Slack tokens.

Optional E2E

  • openclaw-slack-pairing-e2e (high): Useful adjacent confidence for Slack-specific real user flow: Socket Mode/pairing approval depends on Slack plugin/channel availability, but the PR’s direct assertions are covered by the required Slack scenario and messaging-providers E2E.
  • ubuntu-repo-cloud-openclaw (medium): Optional baseline OpenClaw smoke check to ensure the Slack-specific config changes did not regress the default non-messaging OpenClaw onboarding and sandbox lifecycle path.

New E2E recommendations

  • None.

Dispatch hint

  • Workflow: .github/workflows/e2e-scenarios.yaml
  • jobs input: ubuntu-repo-cloud-openclaw-slack

@github-actions

github-actions Bot commented May 26, 2026

Copy link
Copy Markdown
Contributor

E2E Scenario Advisor Recommendation

Required scenario E2E: e2e-scenarios-all, ubuntu-repo-cloud-openclaw-slack:messaging-slack
Optional scenario E2E: None

Dispatch required scenario E2E:

  • gh workflow run e2e-scenarios-all.yaml --ref <pr-head-ref>
  • gh workflow run e2e-scenarios.yaml --ref <pr-head-ref> --field scenarios=ubuntu-repo-cloud-openclaw-slack

Workflow run

Full scenario advisor summary

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

  • e2e-scenarios-all: shared scenario runner/runtime code changed; validation suite lib changed; validation suite messaging-slack changed
    • Dispatch: gh workflow run e2e-scenarios-all.yaml --ref <pr-head-ref>
  • ubuntu-repo-cloud-openclaw-slack:messaging-slack: Scenario ubuntu-repo-cloud-openclaw-slack exercises the changed scenario E2E surface. Changed suite(s): lib, messaging-slack. shared scenario runner/runtime code changed; validation suite lib changed; validation suite messaging-slack changed
    • Dispatch: gh workflow run e2e-scenarios.yaml --ref <pr-head-ref> --field scenarios=ubuntu-repo-cloud-openclaw-slack

Optional scenario E2E

  • None.

Relevant changed files

  • test/e2e-scenario/nemoclaw_scenarios/helpers/emit-context-from-plan.sh
  • test/e2e-scenario/validation_suites/lib/messaging_providers.sh
  • test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh

@github-actions

github-actions Bot commented May 26, 2026

Copy link
Copy Markdown
Contributor

PR Review Advisor

Findings: 1 needs attention, 3 worth checking, 1 nice ideas
Since last review: 0 prior items resolved, 3 still apply, 1 new item found

Review findings

🛠️ Needs attention

  • Slack runtime proof still stops at discovery, not running (test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh:32): Issue Slack channel never starts despite config enabled: true, env vars present, and plugin installed #4189 expects Slack to be installed, configured, and running, with `openclaw channels status --probe` and gateway startup/log evidence. The new scenario check runs `openclaw channels list --all --json --no-color` and accepts `installed=true`, `origin=configured`, and a `default` account. That verifies the previous `not configured, disabled` symptom, but it can still pass if the Slack plugin never starts, never opens Socket Mode, or is absent from the gateway startup path.
    • Recommendation: Extend the scenario to assert the actual running/probe path for the generated Slack config, for example `openclaw channels status --probe --json` or equivalent status evidence for the default Slack account, plus startup evidence that would fail when Slack is configured but not running.
    • Evidence: Linked issue Slack channel never starts despite config enabled: true, env vars present, and plugin installed #4189 reproduction step 7 expects `Slack: installed, configured, running`; step 8 invokes `openclaw channels status --probe`; step 10 checks gateway logs for Slack startup entries. Current diff checks only `openclaw channels list --all --json --no-color` and parses installed/origin/accounts.

🔎 Worth checking

  • Source-of-truth review needed: test/e2e-scenario/validation_suites/lib/messaging_providers.sh remote config read fallback: The advisor marked localized patch analysis as needs_followup.
    • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
    • Evidence: `e2e_messaging_read_config_surface` falls back to `timeout 30 openshell sandbox exec --name "${sandbox_name}" -- cat "${path}"`, but no changed test covers that branch.
  • Enabled Slack startup egress lacks hermetic OpenShell boundary proof (scripts/generate-openclaw-config.py:719): The generator now enables the Slack plugin entry whenever Slack is configured, which activates a credential-bearing REST/Socket Mode integration at gateway startup. The added tests prove generated config shape and OpenClaw discovery, but they do not directly exercise the started plugin against a hermetic fake Slack endpoint through the OpenShell/L7 policy and credential-rewrite boundary.
    • Recommendation: Add or identify an integrated startup-path test that starts OpenClaw from the generated Slack config with a hermetic fake Slack REST/Socket Mode endpoint. Verify bot/app token requests traverse the intended policy/rewrite boundary, unresolved placeholders fail closed, real tokens are not exposed in config/process/logs, and allowed/denied Slack events are enforced by the started plugin.
    • Evidence: `plugin_entries.update({"slack": {"enabled": True}} if "slack" in _ch_cfg else {})` activates Slack; tests assert `channels.slack.enabled`, `plugins.entries.slack.enabled`, and `channels list`, not startup egress or credential rewriting.
  • Slack scenario metadata still omits the required app token (test/e2e-scenario/scenarios/scenarios/baseline.ts:171): Generated OpenClaw Slack config always includes both `botToken` and `appToken`, and Slack Socket Mode requires the app token. The OpenClaw Slack scenario metadata and manifest still list only `SLACK_BOT_TOKEN`, so scenario planning/provisioning can advertise an incomplete credential set just as this PR makes Slack plugin startup active.
    • Recommendation: Include `SLACK_APP_TOKEN` alongside `SLACK_BOT_TOKEN` in the OpenClaw Slack scenario required secrets and manifest credential refs, and update helper validation if `slack-app` is intended to prove app-token-specific behavior.
    • Evidence: `scripts/generate-openclaw-config.py` writes `account["appToken"] = _placeholder(ch, "SLACK_APP_TOKEN")`; `baseline.ts` has `requiredSecrets: ["NVIDIA_API_KEY", "SLACK_BOT_TOKEN"]`; `openclaw-nvidia-slack.yaml` credential refs include `NVIDIA_API_KEY` and `SLACK_BOT_TOKEN` only.

🌱 Nice ideas

  • Remote sandbox config-read fallback lacks targeted coverage (test/e2e-scenario/validation_suites/lib/messaging_providers.sh:116): The helper now falls back from a missing host-side `/sandbox/...` config path to `openshell sandbox exec --name ... -- cat ...`. That is a reasonable host/sandbox boundary fallback, but this PR does not add a focused regression test for the non-dry-run remote-read branch.
    • Recommendation: Add a small helper test with a fake `openshell` executable that proves `e2e_messaging_read_config_surface` reads the fixed sandbox config path when the host path is absent, preserves command argument boundaries, and fails cleanly when the remote read returns empty.
    • Evidence: Existing framework coverage checks provider names, config paths, and dry-run suite wiring; the new `timeout 30 openshell sandbox exec --name "${sandbox_name}" -- cat "${path}"` branch is not directly exercised.
Since last review details

Current findings:

  • Source-of-truth review needed: test/e2e-scenario/validation_suites/lib/messaging_providers.sh remote config read fallback: The advisor marked localized patch analysis as needs_followup.
    • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
    • Evidence: `e2e_messaging_read_config_surface` falls back to `timeout 30 openshell sandbox exec --name "${sandbox_name}" -- cat "${path}"`, but no changed test covers that branch.
  • Slack runtime proof still stops at discovery, not running (test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh:32): Issue Slack channel never starts despite config enabled: true, env vars present, and plugin installed #4189 expects Slack to be installed, configured, and running, with `openclaw channels status --probe` and gateway startup/log evidence. The new scenario check runs `openclaw channels list --all --json --no-color` and accepts `installed=true`, `origin=configured`, and a `default` account. That verifies the previous `not configured, disabled` symptom, but it can still pass if the Slack plugin never starts, never opens Socket Mode, or is absent from the gateway startup path.
    • Recommendation: Extend the scenario to assert the actual running/probe path for the generated Slack config, for example `openclaw channels status --probe --json` or equivalent status evidence for the default Slack account, plus startup evidence that would fail when Slack is configured but not running.
    • Evidence: Linked issue Slack channel never starts despite config enabled: true, env vars present, and plugin installed #4189 reproduction step 7 expects `Slack: installed, configured, running`; step 8 invokes `openclaw channels status --probe`; step 10 checks gateway logs for Slack startup entries. Current diff checks only `openclaw channels list --all --json --no-color` and parses installed/origin/accounts.
  • Enabled Slack startup egress lacks hermetic OpenShell boundary proof (scripts/generate-openclaw-config.py:719): The generator now enables the Slack plugin entry whenever Slack is configured, which activates a credential-bearing REST/Socket Mode integration at gateway startup. The added tests prove generated config shape and OpenClaw discovery, but they do not directly exercise the started plugin against a hermetic fake Slack endpoint through the OpenShell/L7 policy and credential-rewrite boundary.
    • Recommendation: Add or identify an integrated startup-path test that starts OpenClaw from the generated Slack config with a hermetic fake Slack REST/Socket Mode endpoint. Verify bot/app token requests traverse the intended policy/rewrite boundary, unresolved placeholders fail closed, real tokens are not exposed in config/process/logs, and allowed/denied Slack events are enforced by the started plugin.
    • Evidence: `plugin_entries.update({"slack": {"enabled": True}} if "slack" in _ch_cfg else {})` activates Slack; tests assert `channels.slack.enabled`, `plugins.entries.slack.enabled`, and `channels list`, not startup egress or credential rewriting.
  • Slack scenario metadata still omits the required app token (test/e2e-scenario/scenarios/scenarios/baseline.ts:171): Generated OpenClaw Slack config always includes both `botToken` and `appToken`, and Slack Socket Mode requires the app token. The OpenClaw Slack scenario metadata and manifest still list only `SLACK_BOT_TOKEN`, so scenario planning/provisioning can advertise an incomplete credential set just as this PR makes Slack plugin startup active.
    • Recommendation: Include `SLACK_APP_TOKEN` alongside `SLACK_BOT_TOKEN` in the OpenClaw Slack scenario required secrets and manifest credential refs, and update helper validation if `slack-app` is intended to prove app-token-specific behavior.
    • Evidence: `scripts/generate-openclaw-config.py` writes `account["appToken"] = _placeholder(ch, "SLACK_APP_TOKEN")`; `baseline.ts` has `requiredSecrets: ["NVIDIA_API_KEY", "SLACK_BOT_TOKEN"]`; `openclaw-nvidia-slack.yaml` credential refs include `NVIDIA_API_KEY` and `SLACK_BOT_TOKEN` only.
  • Remote sandbox config-read fallback lacks targeted coverage (test/e2e-scenario/validation_suites/lib/messaging_providers.sh:116): The helper now falls back from a missing host-side `/sandbox/...` config path to `openshell sandbox exec --name ... -- cat ...`. That is a reasonable host/sandbox boundary fallback, but this PR does not add a focused regression test for the non-dry-run remote-read branch.
    • Recommendation: Add a small helper test with a fake `openshell` executable that proves `e2e_messaging_read_config_surface` reads the fixed sandbox config path when the host path is absent, preserves command argument boundaries, and fails cleanly when the remote read returns empty.
    • Evidence: Existing framework coverage checks provider names, config paths, and dry-run suite wiring; the new `timeout 30 openshell sandbox exec --name "${sandbox_name}" -- cat "${path}"` branch is not directly exercised.

Workflow run details

This is an automated advisory review. A human maintainer must make the final merge decision.

chengjiew added 2 commits May 27, 2026 17:38
Signed-off-by: Chengjie Wang <chengjiew@nvidia.com>
Signed-off-by: Chengjie Wang <chengjiew@nvidia.com>
@coderabbitai

coderabbitai Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 35abbc9e-9192-4b66-b085-a295b1bdb6df

📥 Commits

Reviewing files that changed from the base of the PR and between 4be23c0 and ffd2c0d.

📒 Files selected for processing (1)
  • test/e2e-scenario/validation_suites/lib/messaging_providers.sh
🚧 Files skipped from review as they are similar to previous changes (1)
  • test/e2e-scenario/validation_suites/lib/messaging_providers.sh

📝 Walkthrough

Walkthrough

Config generator now emits top-level enabled: true for Slack channels and conditionally adds Slack to plugin entries. Unit tests and E2E suite validate both channel and plugin enablement flags are present and set to true in generated configuration.

Changes

Slack channel enablement

Layer / File(s) Summary
Config generator: Slack channel & plugin enablement
scripts/generate-openclaw-config.py
Slack channel config in _ch_cfg now includes a top-level enabled: true flag alongside accounts.default. The Slack plugin entry is conditionally added to the generated plugins configuration only when "slack" exists in the assembled channel config.
Unit tests: Slack enabled assertions
test/generate-openclaw-config.test.ts
Two Slack config-generation tests now assert that the generated config.channels.slack.enabled flag equals true.
E2E validation and helpers: runtime discovery, config surface, and wiring
test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh, test/e2e-scenario/validation_suites/lib/messaging_providers.sh, test/e2e-scenario/nemoclaw_scenarios/helpers/emit-context-from-plan.sh, test/e2e-scenario/framework-tests/e2e-suite-runner.test.ts
E2E Slack provider-state validation now asserts both channels.slack.enabled and plugins.entries.slack.enabled are true, performs an in-sandbox openclaw channels list runtime-discovery check, adds a sandbox-backed fallback for reading config surfaces, conditionally emits E2E_MESSAGING_PROVIDER in emitted context, and updates the test harness expected assertion IDs to include slack.runtime-discovery.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

  • NVIDIA/NemoClaw#1757: Modifies Slack channel config structure under config.channels.slack during config generation to add build-time allowlist injection, updating the same config section where enablement flags are now added.

Suggested labels

fix, Integration: OpenClaw

Suggested reviewers

  • ericksoa
  • cv

Poem

🐰 A Slack flag now shines, enabled true,
Plugin entries wake with morning dew,
Tests nudge gently, "is the channel live?"
E2E listens, checks the runtime hive,
Rabbit hops — the config's through!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: enabling Slack channel config generation by adding the top-level 'enabled' flag to the generated OpenClaw config.
Linked Issues check ✅ Passed The PR changes directly address issue #4189 by ensuring the generated OpenClaw config includes the top-level Slack 'enabled' marker alongside account entries, which was the core objective.
Out of Scope Changes check ✅ Passed All changes are in-scope: config generation (scripts/), unit tests (test/), and e2e validation tests align with the stated objective of ensuring Slack config generation includes the enabled marker.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/4189_slack-channel-start

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

@ericksoa ericksoa added integration: slack Slack integration or channel behavior v0.0.53 Release target labels May 27, 2026
@ericksoa ericksoa added v0.0.54 Release target and removed v0.0.53 Release target labels May 27, 2026
@ericksoa ericksoa self-assigned this May 27, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Selective E2E Results — ❌ Some jobs failed

Run: 26540390546
Target ref: 299e33e8d4b4482ed7b5555773cec3047bf1087b
Workflow ref: main
Requested jobs: messaging-providers-e2e
Summary: 0 passed, 1 failed, 0 skipped

Job Result
messaging-providers-e2e ❌ failure

Failed jobs: messaging-providers-e2e. Check run artifacts for logs.

@github-actions

Copy link
Copy Markdown
Contributor

Selective E2E Results — ✅ All requested jobs passed

Run: 26541299471
Target ref: 63bbc5cc0568a8da53302c362ab478b03fd14376
Workflow ref: main
Requested jobs: messaging-providers-e2e
Summary: 1 passed, 0 failed, 0 skipped

Job Result
messaging-providers-e2e ✅ success

@github-actions

Copy link
Copy Markdown
Contributor

Selective E2E Results — ✅ All requested jobs passed

Run: 26542067616
Target ref: a799a7764528fadd7869873f5d90c54e867f9ee2
Workflow ref: main
Requested jobs: messaging-providers-e2e
Summary: 1 passed, 0 failed, 0 skipped

Job Result
messaging-providers-e2e ✅ success

@ericksoa ericksoa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved after current-head CI is green and messaging-providers nightly validation passed on a799a77.

@ericksoa ericksoa enabled auto-merge (squash) May 27, 2026 23:10

@ericksoa ericksoa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved on current head 977676b after moving the Slack E2E assertion to the scenario messaging suite and clearing the current codebase-growth guardrails.

@ericksoa ericksoa left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-approved current head 4be23c0 after moving Slack runtime proof fully into scenario E2E and keeping guardrails green.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh (1)

19-21: ⚡ Quick win

Consider splitting assertions for more specific error messages.

The current Python one-liner will fail with the same generic message whether channels.slack.enabled is missing, plugins.entries.slack.enabled is missing, either is false, or the JSON structure is malformed. Splitting into separate assertions or adding try/except would help pinpoint the exact failure during CI debugging.

🔍 Example: separate assertions for clearer errors
-    if ! printf '%s\n' "${content}" | python3 -c 'import json, sys; cfg=json.load(sys.stdin); assert cfg["channels"]["slack"]["enabled"] is True; assert cfg["plugins"]["entries"]["slack"]["enabled"] is True'; then
-      e2e_fail "expected-state.messaging.slack.openclaw-enabled missing channels.slack.enabled or plugins.entries.slack.enabled"
+    if ! printf '%s\n' "${content}" | python3 -c 'import json, sys; cfg=json.load(sys.stdin); assert cfg.get("channels", {}).get("slack", {}).get("enabled") is True, "channels.slack.enabled not true"'; then
+      e2e_fail "expected-state.messaging.slack.openclaw-enabled channels.slack.enabled missing or not true"
+    fi
+    if ! printf '%s\n' "${content}" | python3 -c 'import json, sys; cfg=json.load(sys.stdin); assert cfg.get("plugins", {}).get("entries", {}).get("slack", {}).get("enabled") is True, "plugins.entries.slack.enabled not true"'; then
+      e2e_fail "expected-state.messaging.slack.openclaw-enabled plugins.entries.slack.enabled missing or not true"
     fi
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh`
around lines 19 - 21, The combined python one-liner that reads from "${content}"
and asserts both cfg["channels"]["slack"]["enabled"] and
cfg["plugins"]["entries"]["slack"]["enabled"] should be split into two distinct
checks (or a try/except that emits specific errors) so failures are actionable;
update the python3 -c invocation that consumes "${content}" (or replace with two
invocations) to first verify cfg["channels"]["slack"]["enabled"] and call
e2e_fail with a clear message if missing/false, then separately verify
cfg["plugins"]["entries"]["slack"]["enabled"] with its own e2e_fail message, and
also handle JSON parse/missing-key exceptions to surface helpful diagnostics
instead of a single generic failure.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In
`@test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh`:
- Around line 19-21: The combined python one-liner that reads from "${content}"
and asserts both cfg["channels"]["slack"]["enabled"] and
cfg["plugins"]["entries"]["slack"]["enabled"] should be split into two distinct
checks (or a try/except that emits specific errors) so failures are actionable;
update the python3 -c invocation that consumes "${content}" (or replace with two
invocations) to first verify cfg["channels"]["slack"]["enabled"] and call
e2e_fail with a clear message if missing/false, then separately verify
cfg["plugins"]["entries"]["slack"]["enabled"] with its own e2e_fail message, and
also handle JSON parse/missing-key exceptions to surface helpful diagnostics
instead of a single generic failure.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 0730f6b2-f1e1-4888-ab4b-cb8d999cb24b

📥 Commits

Reviewing files that changed from the base of the PR and between 98d4dc1 and 977676b.

📒 Files selected for processing (1)
  • test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh

@github-actions

Copy link
Copy Markdown
Contributor

Selective E2E Results — ✅ All requested jobs passed

Run: 26544683761
Target ref: 4be23c067ae3fa32cdcb6604bd51a9b6e79523a8
Workflow ref: main
Requested jobs: messaging-providers-e2e
Summary: 1 passed, 0 failed, 0 skipped

Job Result
messaging-providers-e2e ✅ success

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/e2e-scenario/validation_suites/lib/messaging_providers.sh`:
- Line 119: The command that assigns remote using openshell—remote="$(openshell
sandbox exec --name "${sandbox_name}" -- cat "${path}" 2>/dev/null || true)"—can
hang; wrap the sandbox exec call with a timeout (e.g., the timeout utility or
the openshell --timeout option if available) so the command is forcibly killed
after a short period (e.g., 20–30s) and the script continues; update the
invocation so failures still fall back to || true and ensure any timeout exit
codes are handled the same way.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 7cb748ea-7b6e-4019-8425-eafd90c69365

📥 Commits

Reviewing files that changed from the base of the PR and between 977676b and 4be23c0.

📒 Files selected for processing (4)
  • test/e2e-scenario/framework-tests/e2e-suite-runner.test.ts
  • test/e2e-scenario/nemoclaw_scenarios/helpers/emit-context-from-plan.sh
  • test/e2e-scenario/validation_suites/lib/messaging_providers.sh
  • test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh
🚧 Files skipped from review as they are similar to previous changes (1)
  • test/e2e-scenario/validation_suites/messaging/slack/00-slack-provider-state.sh

Comment thread test/e2e-scenario/validation_suites/lib/messaging_providers.sh Outdated
@ericksoa ericksoa merged commit 1daf081 into main May 27, 2026
21 checks passed
@ericksoa ericksoa deleted the fix/4189_slack-channel-start branch May 27, 2026 23:47
ericksoa added a commit that referenced this pull request May 28, 2026
…ter rebuild (#4403)

## Summary

Fixes #4314
Fixes #4390

This is now the unified messaging-channel PR: it keeps the original
#4403 runtime verification path and folds in the full #4400 OpenClaw
channel activation / plugin-build / E2E coverage set.

OpenClaw 2026.5.22+ no longer auto-starts a messaging bridge from the
account-level `enabled` flag alone — the channel must also be marked
enabled at the top level for the bridge module to load. NemoClaw#4189
fixed this for Slack (PR #4222); the same gap silently produced "no
Telegram process / no logs" for Telegram (#4314, #4390) and would
silently break Discord too.

This PR:

- Bakes `channels.<name>.enabled: true` for Telegram, Discord, Slack,
and WhatsApp in generated `openclaw.json`.
- Enables matching `plugins.entries.<channel>` records so OpenClaw
discovers selected messaging providers through its real channel/plugin
path.
- Pins external OpenClaw messaging plugins at image build time with
`scripts/openclaw-build-messaging-plugins.py` instead of relying on
unversioned `openclaw doctor --fix` catalog drift.
- Adds a gated Telegram startup-grace diagnostic breadcrumb when the
bridge fails to log startup within the grace window.
- Adds a post-rebuild runtime check to `nemoclaw <sandbox> channels add
<channel>` for verifiable OpenClaw channels (telegram/discord/slack),
surfacing missing enabled flags, missing startup breadcrumbs, and
credential/startup warnings.
- Extends messaging-provider E2E coverage with generated activation
checks, `openclaw channels list --all --json` runtime discovery checks,
pinned plugin build coverage, fake provider APIs, and optional live
Telegram/Discord/Slack `openclaw message send` paths when repository
secrets are configured.
- Keeps WeChat out of upfront generated channel config; WeChat remains
on the existing late seed path after plugin install.

## Reproduction (issue #4390 + #4314)

Before the fix, generated config with Telegram selected during
onboarding:

```json
"channels": { "telegram": { "accounts": { "default": { ... } } } }
```

No top-level `enabled: true` meant OpenClaw skipped loading the bridge.
No Telegram process spawned, `/sandbox/.openclaw/telegram/` stayed
empty, and no startup/error breadcrumb appeared.

After the fix:

```json
"channels": { "telegram": { "enabled": true, "accounts": { "default": { ..., "enabled": true } } } }
```

The bridge module is loadable, diagnostics can report silent startup
failure, and `channels add telegram` probes the rebuilt runtime instead
of leaving users with radio silence.

## Test plan

Local validation on the unified branch:

- [x] `python3 -m py_compile scripts/generate-openclaw-config.py
scripts/openclaw-build-messaging-plugins.py`
- [x] `NEMOCLAW_MESSAGING_CHANNELS_B64=$(printf '%s'
'["telegram","discord","slack","whatsapp"]' | base64 | tr -d '\n')
OPENCLAW_VERSION=2026.5.22 python3
scripts/openclaw-build-messaging-plugins.py --dry-run`
- [x] `bash -n test/e2e/test-messaging-providers.sh
test/e2e/lib/discord-rest-policy-proof.sh
test/e2e/lib/slack-api-proof.sh test/e2e/lib/telegram-api-proof.sh`
- [x] `git diff --check HEAD~1..HEAD`
- [x] `npm ci --ignore-scripts`
- [x] `npm run build:cli`
- [x] `npx vitest run test/generate-openclaw-config.test.ts
test/openclaw-build-messaging-plugins.test.ts
test/sandbox-build-context.test.ts test/sandbox-provisioning.test.ts
test/channels-add-preset.test.ts test/telegram-diagnostics.test.ts
test/e2e-script-workflow.test.ts test/validate-e2e-coverage.test.ts` —
160 passed

Live Telegram bot E2E was not run from the local triage worktree because
no Telegram bot credential is available locally; the PR wires optional
live repository secrets through the nightly reusable workflow and keeps
hermetic fake-provider proofs for CI.

## DCO

```
Signed-off-by: Yimo Jiang <yimoj@nvidia.com>
```

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Startup watchdog emits a single breadcrumb when an OpenClaw gateway
bridge fails to start within a configurable grace period.
  * Post-channel-add now verifies bridged channels after a rebuild.
* Image/sandbox build now includes a messaging-plugin installer to
pin/install provider plugins.

* **Bug Fixes**
* Ensure channels, accounts, and plugin entries are marked enabled so
bridges activate reliably.

* **Tests**
* Expanded regression/E2E coverage with fake provider APIs, startup
diagnostics, and live-credential wiring for Telegram/Discord/Slack.

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/NVIDIA/NemoClaw/pull/4403?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)

<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: Yimo Jiang <yimoj@nvidia.com>
Co-authored-by: Aaron Erickson <aerickson@nvidia.com>
@miyoungc miyoungc mentioned this pull request May 29, 2026
12 tasks
miyoungc added a commit that referenced this pull request May 29, 2026
## Summary
Refreshes the NemoClaw documentation for the v0.0.54 release and
regenerates user skills from the Fern MDX source. Also keeps the Fern
CLI pin current so local docs checks use the upgraded Fern version.

## Related Issue
<!-- No single related issue. This is release-prep documentation
catch-up. -->

## Changes
- #4403 -> `docs/manage-sandboxes/messaging-channels.mdx`,
`docs/reference/commands.mdx`, `docs/about/release-notes.mdx`: Document
Telegram, Discord, and Slack post-rebuild bridge verification and
summarize channel activation fixes.
- #4222 -> `docs/about/release-notes.mdx`: Include Slack generated
channel enablement in the v0.0.54 messaging summary.
- #4346 -> `docs/get-started/windows-preparation.mdx`,
`docs/about/release-notes.mdx`: Document safer Windows bootstrap
behavior for Ubuntu first-run and Docker Desktop WSL integration.
- #4416 -> `docs/inference/use-local-inference.mdx`,
`docs/about/release-notes.mdx`: Document the Docker Desktop WSL
requirement for Windows-host Ollama.
- #4442 -> `docs/about/release-notes.mdx`: Summarize the optional
NemoHermes native web dashboard and related environment variables.
- #4426 -> `docs/about/release-notes.mdx`: Summarize copy-paste recovery
hints for invalid sandbox names and missing NVIDIA API keys.
- #4459 -> `docs/about/release-notes.mdx`: Summarize the Linuxbrew
prefix fix for sandbox Homebrew usage.
- #4450 -> `docs/about/release-notes.mdx`: Summarize `/nemoclaw` slash
command startup activation.
- #4468 -> `docs/about/release-notes.mdx`: Summarize scope-upgrade
approval recovery.
- #4325 -> `docs/about/release-notes.mdx`: Summarize the narrowed
`web_fetch` host-gateway allowance.
- #4474 -> `docs/about/release-notes.mdx`: Summarize Hermes Provider
smoke-check behavior for OAuth versus Nous API key setup.
- Refresh generated `.agents/skills/nemoclaw-user-*` references from
`docs/` and update `fern/fern.config.json` to Fern `5.41.2`.

## Type of Change
- [ ] Code change (feature, bug fix, or refactor)
- [ ] Code change with doc updates
- [x] Doc only (prose changes, no code sample modifications)
- [ ] Doc only (includes code sample changes)

## Verification
<!-- Check each item you ran and confirmed. Leave unchecked items you
skipped. Doc-only changes do not require npm test unless you ran it. -->
- [ ] `npx prek run --all-files` passes
- [ ] `npm test` passes
- [ ] Tests added or updated for new or changed behavior
- [x] No secrets, API keys, or credentials committed
- [x] Docs updated for user-facing behavior changes
- [ ] `npm run docs` builds without warnings (doc changes only)
- [x] Doc pages follow the [style
guide](https://github.com/NVIDIA/NemoClaw/blob/main/docs/CONTRIBUTING.md)
(doc changes only)
- [ ] New doc pages include SPDX header and frontmatter (new pages only)

---
<!-- DCO sign-off required by CI. Run: git config user.name && git
config user.email -->
Signed-off-by: Miyoung Choi <miyoungc@nvidia.com>

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
  * Optional NemoHermes native web dashboard (configurable port and TUI)
* GPU memory cleanup now unloads Ollama models when switching providers
or stopping services

* **Bug Fixes**
  * Improved sandbox name validation with suggested slug recovery
* Windows-host Ollama now requires Docker Desktop WSL integration and
exits with remediation guidance when unsupported

* **Documentation**
* Clarified quickstart/onboard flow, installer TTY/non‑TTY guidance,
Hermes Docker prerequisites, sandbox hardening, and channels add rebuild
checks

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/NVIDIA/NemoClaw/pull/4539?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)

<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
@wscurran wscurran added the bug-fix PR fixes a bug or regression label Jun 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug-fix PR fixes a bug or regression integration: slack Slack integration or channel behavior v0.0.54 Release target

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Slack channel never starts despite config enabled: true, env vars present, and plugin installed

4 participants