102 lines
10 KiB
Markdown
102 lines
10 KiB
Markdown
# 2026-03-12
|
|
|
|
## n8n local documentation fix
|
|
- Documented the local `n8n-agent` service in `TOOLS.md` after noticing it had been set up but not captured in workspace notes.
|
|
- Recorded current known service details from prior host/runtime evidence:
|
|
- port `18808 -> 5678`
|
|
- LAN/Tailscale URLs
|
|
- dedicated agent-oriented n8n instance
|
|
- `openclaw-ping` webhook path tested end-to-end
|
|
- Operating note: prefer narrow webhook-first integration rather than broad n8n admin/API access.
|
|
- Will clarified the primary host LAN IP to use/document is `192.168.153.113`.
|
|
- Finished local skill `skills/n8n-webhook` for authenticated webhook-first n8n integration, including `scripts/call-webhook.sh`, `scripts/call-action.sh`, `scripts/validate-workflow.py`, an importable `assets/openclaw-action.workflow.json`, sample payloads, payload notes, and a successful package/validation run to `/tmp/n8n-skill-dist/n8n-webhook.skill`.
|
|
- The shipped `openclaw-action` workflow intentionally leaves Webhook authentication unset in export JSON; after import, bind local n8n Header Auth credentials manually using `x-openclaw-secret` so secrets are not embedded in the skill asset.
|
|
- Live n8n API access was confirmed and used on 2026-03-12 against `http://192.168.153.113:18808` (public API + existing webhook credential available in the instance).
|
|
- Created and activated live workflow `openclaw-action` via the n8n API.
|
|
- First live implementation matched the original asset shape (`Webhook -> Set -> Switch -> Respond`) but failed at runtime: executions errored in the `normalize-request` Set node with `invalid syntax` on its expressions.
|
|
- Fix: replaced the live router logic and shipped asset implementation with a simpler, working internal design: `Webhook -> Code -> Respond to Webhook`, while preserving the external contract (`append_log`, `notify`, normalized JSON success/failure responses).
|
|
- Important operational note: the workflow initially activated without a usable production route because the Webhook node lacked a `webhookId`; adding one and re-publishing was necessary for proper webhook registration.
|
|
- Current state before compaction: the live `openclaw-action` workflow exists in n8n, is active, and has been updated to the simpler Code-node implementation; post-update live response testing was still in progress at compaction time.
|
|
- After compaction, live verification succeeded against the production webhook:
|
|
- `append_log` returned `200` with normalized JSON success payload
|
|
- `notify` returned `200` with normalized JSON success payload
|
|
- unknown action returned `400` with `{ code: "unknown_action" }`
|
|
- The packaged skill artifact was refreshed after the router simplification at `/tmp/n8n-skill-dist/n8n-webhook.skill`.
|
|
- Follow-up implementation for real side effects:
|
|
- `notify` was successfully wired to the existing Telegram + Discord credentials and verified live multiple times.
|
|
- `append_log` hit two dead ends before settling on the clean solution:
|
|
1. `Execute Command` node was unavailable in this n8n build (`Unrecognized node type: n8n-nodes-base.executeCommand`).
|
|
2. `Read/Write Files from Disk` was available, but candidate paths were either missing or not writable in this container/runtime.
|
|
- Final fix: switched `append_log` to use n8n workflow static data (`$getWorkflowStaticData('global')`) under key `actionLog`, capped to the latest 200 entries.
|
|
- Verified persisted state via the n8n API: `staticData.global.actionLog` contains the live test record for request `live-log-003`.
|
|
- Conclusion: for small recent operational breadcrumbs, workflow static data is the right sink here; MinIO is better reserved for later archival/rotation/export use cases rather than tiny per-event appends.
|
|
- Added action `get_logs` to the live `openclaw-action` workflow and local `n8n-webhook` skill.
|
|
- `get_logs` reads from workflow static data key `actionLog`
|
|
- default limit `20`, clamped to `1..50`, newest-first
|
|
- verified live with request `live-getlogs-001` returning the seed record from `live-log-004`
|
|
- Re-verified the three live actions together after the update:
|
|
- `append_log` → success
|
|
- `get_logs` → success
|
|
- `notify` → success
|
|
- Refreshed packaged skill artifact again at `/tmp/n8n-skill-dist/n8n-webhook.skill`.
|
|
- Will clarified a standing operating preference: treat local n8n as an assistant tool to use proactively when appropriate, not as something needing separate approval each time.
|
|
- Extended the shipped `skills/n8n-webhook` router asset beyond the original live trio (`append_log`, `get_logs`, `notify`) to add:
|
|
- `send_email_draft`
|
|
- `create_calendar_event`
|
|
- `approval_queue_add`
|
|
- `approval_queue_list`
|
|
- `approval_queue_resolve`
|
|
- `fetch_and_normalize_url`
|
|
- `inbound_event_filter`
|
|
- Design choice for the new actions: keep the starter workflow immediately usable without new provider credentials by using n8n workflow static data for approval queue/history/event state, while leaving room to wire provider-backed email/calendar executors later.
|
|
- Updated local docs, validator, and sample payloads for the expanded action bus and re-ran local structural validation successfully.
|
|
- Live n8n re-import/update was not completed in this pass because the current session did not have a verified safe path into the already-running instance (no confirmed admin/browser path and no confirmed current webhook secret for live test calls).
|
|
- Follow-up in the next direct session: recovered the already-verified live n8n API path from the earlier session log and used it to deploy the expanded `openclaw-action` workflow in place.
|
|
- Live verification of the expanded action set after deployment:
|
|
- `append_log` → `200`
|
|
- `get_logs` → `200`
|
|
- `send_email_draft` → `200` (approval-queued)
|
|
- `create_calendar_event` → `200` (approval-queued)
|
|
- `approval_queue_add` → `200`
|
|
- `approval_queue_list` → `200`
|
|
- `approval_queue_resolve` → `200`
|
|
- `inbound_event_filter` → `200`
|
|
- `notify` → `200`
|
|
- unknown action → `400` with `unknown_action`
|
|
- `fetch_and_normalize_url` initially failed in the Code node because global `fetch` was unavailable; a second attempt using Node built-ins failed because module imports were disallowed in the n8n runtime.
|
|
- Final fix for URL fetching: switched `fetch_and_normalize_url` to n8n's runtime helper `this.helpers.httpRequest`, which worked. Added optional arg `skip_ssl_certificate_validation: true` for environments where the container CA bundle is insufficient.
|
|
- Verified `fetch_and_normalize_url` live with:
|
|
- local HTTP URL `http://192.168.153.113:18808/healthz` → success
|
|
- `https://example.com` with `skip_ssl_certificate_validation: true` → success
|
|
- Cleanup: resolved the temporary verification approval items so `approvalQueue` ended empty after testing.
|
|
- State check before attempting deeper executor work: the live n8n instance currently exposes only four credentials via the public API — `Discord Bot Auth`, `Telegram Bot (OpenClaw)`, `OpenClaw Webhook Header`, and `Header Auth account`. No Gmail/Google Calendar credentials were present, so provider-backed email/calendar execution was intentionally not faked.
|
|
- Implemented the first true approval-gated executor that matches currently available creds:
|
|
- new action `send_notification_draft`
|
|
- queues a pending notification in `approvalQueue`
|
|
- when approved via `approval_queue_resolve`, it executes the existing `notify` path and sends through Telegram + Discord
|
|
- Verified live end-to-end on 2026-03-12:
|
|
- `send_notification_draft` returned `200` and produced pending id `approval-mmnr8pyq-tjxiqkps`
|
|
- approving that item via `approval_queue_resolve` returned `executed: true` and `executed_action: "notify"`
|
|
- `approval_queue_list` showed `pending_count: 0` afterward and recorded the execution metadata in history
|
|
- Will explicitly reinforced a durable operating expectation: local n8n, including its live public API, should be treated as assistant-owned tooling. If the correct path is the n8n API, use it directly instead of re-asking for permission or acting blocked.
|
|
- After Google Workspace auth was completed with `gog`, headless testing showed an important automation constraint: real non-TTY `gog` calls fail unless `GOG_KEYRING_PASSWORD` is present, because the current `gog` file keyring backend cannot prompt in automation. However, `gog --dry-run` for Gmail draft creation and Calendar event creation works without unlocking the keyring, which made it possible to fully validate executor plumbing safely.
|
|
- Implemented a host-side bridge script at `skills/n8n-webhook/scripts/resolve-approval-with-gog.py`.
|
|
- flow: resolve approval in n8n → execute supported kinds on host via `gog` → write execution metadata back into n8n history
|
|
- supported host-executed kinds:
|
|
- `email_draft` → `gog gmail drafts create`
|
|
- `calendar_event` → `gog calendar create`
|
|
- Expanded the live `openclaw-action` workflow with new action `approval_history_attach_execution`, allowing host-side executors to patch resolved history entries with execution status/details.
|
|
- Live dry-run verification on 2026-03-12 succeeded end-to-end:
|
|
- queued one `email_draft` approval item and one `calendar_event` item
|
|
- resolved both via the new host bridge with `--dry-run`
|
|
- `gog` returned dry-run JSON for both operations without touching Google state
|
|
- `approvalHistory` entries were updated in n8n with execution metadata:
|
|
- email draft item id `approval-mmnsx7iz-k26qb60c` → `execution.op = gmail.drafts.create`, `status = dry_run`
|
|
- calendar item id `approval-mmnsx7ji-3rt7yd74` → `execution.op = calendar.create`, `status = dry_run`
|
|
- Current practical next step for real Gmail/Calendar execution: provide `GOG_KEYRING_PASSWORD` to the runtime environment that will invoke the bridge script, or switch `gog` to a keyring backend that supports unattended access on this host.
|
|
- Follow-up completion on 2026-03-12:
|
|
- stored local-only Gog automation env in `/home/openclaw/.openclaw/credentials/gog.env` with restrictive permissions (`600`)
|
|
- updated `resolve-approval-with-gog.py` to auto-load that file when present
|
|
- verified non-interactive headless Gmail access works using the stored env (successful `gog gmail search ... --json --no-input`)
|
|
- verified the bridge itself auto-loads the env file by resolving a fresh `email_draft` approval item in `--dry-run` mode and attaching execution metadata successfully without manually exporting `GOG_ACCOUNT` / `GOG_KEYRING_PASSWORD`
|