feat: v0.3.0 — room automation + comment polling#6
Conversation
Add OpenClaw room-triggered automation engine with rule-based matching (keyword, sender, room, regex) and bounded actions (post, exec, nudge). Add comment polling for Moltbook posts and GitHub issues/discussions. Add Moltbook connector for posting and feed reading. Update config defaults for new automation and comments sections. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4e53360826
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
src/comment-poller.mjs
Outdated
| `curl -sS ${authHeader} "https://api.github.com/repos/${owner}/${repo}/issues?state=open&sort=updated&direction=desc&per_page=10"`, | ||
| { encoding: 'utf8', timeout: 15000 } | ||
| ); | ||
| return JSON.parse(result); |
There was a problem hiding this comment.
When GitHub returns an error payload object (for example on bad credentials or rate limiting), fetchGitHubIssues returns that object directly from JSON.parse, but pollComments later assumes it is iterable with for (const issue of issues). In that case the poller throws TypeError: issues is not iterable and aborts the whole polling pass instead of skipping that source, so comment ingestion can stop entirely until restart.
Useful? React with 👍 / 👎.
| .replace(/\$\{sender\}/g, msg.user?.handle || msg.from || '?') | ||
| .replace(/\$\{body\}/g, (msg.body || '').slice(0, 200)); | ||
|
|
||
| if (action.type === 'post') { |
There was a problem hiding this comment.
type
executeAction reads action.type unconditionally, so a rule missing its action block (or with action: null) throws before the unknown action type fallback can run. Because this happens inside the poll loop, one malformed rule can crash automation processing for all rooms instead of being safely skipped with a receipt.
Useful? React with 👍 / 👎.
Address Codex review findings on PR #6: - P1: fetchGitHubIssues now guards against non-array responses (error payloads, rate limiting) that would crash the poll loop - P2: executeAction now handles null/missing action blocks gracefully with a skipped receipt instead of throwing Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 participant
Summary
src/room-automation.mjs): rule-based matching (keyword, sender, room, regex) → bounded actions (post, exec, nudge) with receipts and cooldownssrc/comment-poller.mjs): polls Moltbook posts and GitHub issues/discussions for new comments, writes to event queuesrc/moltbook.mjs): post with challenge-verify flow, feed readingautomationandcommentssectionsTest plan
node --test test/*.test.mjs)--helpshowsautomateandcommentscommands🤖 Generated with Claude Code