docs(rocketchat): add a local verification recipe - #5293
Conversation
Closes verify issue Tracer-Cloud#5152 — no bug found. Adds the missing local quick-start (Docker stack, PAT generation, real verify + tool output, teardown) and documents two real gotchas hit live: the required --platform linux/amd64 + mongo:7.0 pairing, and global 2FA blocking PAT generation unless disabled and the container restarted.
Greptile code reviewThis repo uses Greptile for automated review. Before merge, aim for Confidence Score: 5/5 with zero unresolved review threads — see CONTRIBUTING.md. Run a review — add a PR comment with: Give it ~5-10 minutes (sometimes longer) for results, then fix feedback and re-trigger until you reach Confidence Score: 5/5. Optional: automate with the greploop skill. |
Greptile SummaryThe PR adds a Docker-based local verification recipe for Rocket.Chat token mode.
Confidence Score: 5/5The PR appears safe to merge because no blocking failure remains. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| docs/messaging/rocketchat.mdx | Adds a complete local Rocket.Chat verification workflow using pinned containers and the supported watchdog delivery path. |
Reviews (4): Last reviewed commit: "docs(rocketchat): proactively bound both..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
rocket.chat:latest is a moving target whose bootstrap vars and 2FA defaults this recipe depends on; pinned to 8.5.1, the version the recipe was actually verified against. Re-ran the full recipe (including the 2FA workaround) against the pinned tag to confirm it still reproduces. Also notes RocketChatSendMessageTool is an internal class shown for illustration, not a public API.
|
@greptile review |
|
From OpenSRE Bot in Slack: ✅ PR #5293 — docs(rocketchat): add a local verification recipeWhat it does: Adds a local Docker-based verification recipe for the Rocket.Chat integration, consistent with the rest of this batch (#5287–#5290). Rocket.Chat has a Docker image (rocket.chat + MongoDB), so a self-contained local setup is feasible. Closes the verification gap for Rocket.Chat's registered tools. Assessment: Docs-only, same proven pattern. Worth a quick check that the recipe covers the admin token setup (Rocket.Chat's auth flow requires generating a personal access token, which is the most common stumbling block). Verdict: ✅ Merge — no code risk, fills a real gap. |
- Bind the Rocket.Chat port to loopback (127.0.0.1:3201:3000); the disposable admin account was otherwise reachable on every host interface. - Replace the fixed 'sleep 8' before rs.initiate() with a real mongosh ping readiness loop -- 8s isn't reliable under amd64 emulation on Apple Silicon and could race Mongo startup. - Replace the direct RocketChatSendMessageTool() instantiation with 'opensre watchdog --provider rocketchat', the actual supported delivery path. Verified live: a real alarm message landed in #general within seconds, going through real threshold detection, cooldown, and provider routing instead of bypassing the tool approval flow for a mutating side effect.
|
@greptile review |
… Greptile pattern
The mongo readiness loop had no retry bound, and the Rocket.Chat
service readiness was prose only ('Wait for curl ... to return 200')
with no actual command -- the same defects Greptile found on the
temporal, opensearch, and mysql PRs. Added real bounded loops (30 and
40 retries respectively) with clear failure messages. Verified live
end to end.
|
@greptile review |
| docker run -d --name rc-mongo --network rc-net --platform linux/amd64 \ | ||
| mongo:7.0 --replSet rs0 --bind_ip_all | ||
| i=0; until docker exec rc-mongo mongosh --quiet --eval "db.runCommand('ping')" > /dev/null 2>&1 || [ $i -ge 30 ]; do sleep 2; i=$((i+1)); done | ||
| [ $i -lt 30 ] || { echo "ERROR: MongoDB never became ready" >&2; exit 1; } |
There was a problem hiding this comment.
P1 — the bounded loops reject a successful final poll. The same pattern appears again for Rocket.Chat at lines 130–131: success when the counter equals its limit exits the until loop, then the strict < limit check reports a timeout. Use an explicit readiness flag for both waits.
| Then log in and generate a PAT via the API: | ||
|
|
||
| ```bash | ||
| curl -s -X POST http://localhost:3201/api/v1/login -d "user=verifyadmin&password=verify-admin-pass" |
There was a problem hiding this comment.
P1 — keep credentials out of argv, shell history, and terminal output. This command embeds the admin password in the command line, prints a session token, and the next command places that token in a header argument; even on loopback those values can leak through history/process inspection. It also adds raw vendor endpoints contrary to the user-doc policy. Reuse the already documented Rocket.Chat UI PAT flow, then save it through opensre integrations setup rocketchat; use the admin UI rather than a direct database update for the disposable 2FA setting.
2 participants
Part of #5152
Describe the changes you have made in this PR -
docs/messaging/rocketchat.mdxhad no local-development path. Verified the registeredrocketchat_send_messagetool live against a fresh Rocket.Chat + MongoDB stack (no bugs found), then wrote up the exact recipe. Hit two real, reproducible gotchas along the way and documented both: (1) Rocket.Chat has no arm64 image and MongoDB 8.0 refuses to start under Docker Desktop on Apple Silicon, requiring--platform linux/amd64+mongo:7.0; (2) the image ships with global 2FA enabled and email-based 2FA auto-opt-in, so PAT generation fails withtotp-requireduntil the setting is disabled directly and the container restarted (settings are cached in-process). Added the full recipe: bring-up, PAT generation (including the 2FA workaround), verify output, one real tool call/result, and teardown.Demo/Screenshot for feature changes and bug fixes -
{"source": "rocketchat", "available": true, "status": "sent", "sent": true, "channel": "#general", "message_length": 67}Every command in the doc was run verbatim against a real local Rocket.Chat + MongoDB stack, including reproducing the TOTP failure before working around it.
Code Understanding and AI Usage
Did you use AI assistance (ChatGPT, Claude, Copilot, etc.) to write any part of this code?
If you used AI assistance:
Explain your implementation approach:
Docs-only change, no application code. The verify issue found no bug in the tool itself, but standing up a local Rocket.Chat to reproduce that verification hit two real environment gotchas (platform/MongoDB version, and 2FA blocking token generation) that would otherwise cost the next contributor real time to debug. Documented both as reproduced, with the exact fix, rather than glossing over them.
Checklist before requesting a review
Note: Please check Allow edits from maintainers if you would like us to assist in the PR.