2026 OpenClaw MeshMac: YouTrack Webhook → Multi-Node Build Status Broadcast & Failure Summary

YouTrack Webhook Triggers configuration

JetBrains documents the Webhook Triggers app for YouTrack Cloud: administrators attach it to projects, generate a long random webhook token (JetBrains recommends a 64-character hex value from openssl rand -hex 32), choose the HTTP header that carries the token (default X-YouTrack-Token), and paste one or more HTTPS URLs per event. Use HTTPS only; plaintext delivery exposes the token and issue payloads on the wire.

1. Scope events. Start with issueUpdated (or a narrower subset) so moving a workflow column to “Building” maps cleanly. Add a catch-all URL only after your mapper handles noise.
2. Single gateway URL. Point every URL field at https://<gateway>/youtrack/webhook on the OpenClaw host, not at individual Macs. That keeps the notification loop stable when you add nodes.
3. Permissions. You need admin rights to install the app and project update rights to edit settings—document who owns rotation so vacations do not stall fixes.

Payloads are JSON with fields such as event, timestamp, id, numberInProject, summary, and project.shortName; issueUpdated includes changedFields arrays you can filter before enqueueing work.

Inbound verification (shared token header)

Unlike providers that HMAC the raw body, Webhook Triggers ship authentication as a shared secret in a header. Your gateway must read the configured header name, compare the value to the secret you stored offline, and reject forgeries before JSON parsing widens the attack surface.

1. Store the token with tight POSIX permissions (for example mode 0440) under a path only the gateway user reads, mirroring the MeshMac secrets baseline you already use for other outbound webhooks.
2. Constant-time compare the header bytes to the file contents; return 401 on mismatch and log redacted metadata (never echo the token).
3. Optional defense in depth: IP allowlists for known YouTrack egress, mutual TLS at the edge, or a private relay—especially if the gateway sits on a shared VPC.

If verification passes, parse application/json, attach a correlation_id, and only then enqueue durable work so YouTrack’s automatic retries on non-2xx responses do not create phantom jobs.

Multi-node routing on MeshMac

Treat MeshMac builders as interchangeable workers: the gateway owns external trust, workers own Xcode and disk. After verification, normalize each event into a compact task record (issue_id, project, requested_by, git ref, script name, idempotency_key) and push it to the shared queue your nodes already consume. Follow multi-node deploy and task queue sync for ordering, back-pressure, and mesh_node_id labeling on completion events.

1. Return 200 only after durable enqueue so YouTrack retries do not double-run expensive builds; idempotency keys should blend issue id with normalized transition intent.
2. Keep outbound chat URLs on the gateway so Slack, Teams, or Matrix integrations stay aligned with other MeshMac OpenClaw playbooks you already run from the ingress host.
3. Separate lanes when the same issue also triggers hosted CI—document queue priorities so remote Mac scripts and cloud runners do not fight for signing identities.

The outcome is predictable collaboration: designers and developers read one chat transcript while any healthy node supplies compute, which is the operational definition of “multi-machine synergy” without duplicating secrets.

Retry, backoff, and summary back to YouTrack

Split inbound retries (YouTrack → gateway) from outbound retries (gateway → chat REST and YouTrack REST). Inbound: acknowledge quickly once the enqueue commits so YouTrack stops retrying; if enqueue fails, return 500 deliberately so JetBrains retries with backoff. Outbound: apply exponential backoff with full jitter to 429 and 5xx, cap attempts, and dedupe notifications on idempotency_key + state for at least one hour. Detailed knobs live in task queue retry steps.

Post failure summaries as short issue comments through YouTrack’s REST API using a permanent token scoped to comment-only operations. Keep comments under five lines: emoji state, commit SHA, mesh_node_id, log tail or test name, and a link to archived logs. On repeated API failure after retries, page on-call via the IM binding pattern in IM alerts and token rotation so the notification loop never silently stalls.

This closes the loop for small teams: issue motion triggers automation, automation returns human-readable state in the tracker the team already trusts, and operators get alerted when both chat and tracker paths fail.

Token rotation checklist

1. Webhook token: generate a new secret, deploy it to the gateway file, update YouTrack’s Webhook Triggers settings, send a synthetic issue transition, then revoke the old value from backups.
2. Permanent token for REST: mint the replacement in Hub, grant least privilege, dual-run both tokens for fifteen minutes while gateways reload, then delete the legacy token.
3. Document rotation owners and calendars (quarterly minimum, immediate on incident) so multi-node meshes do not drift when contractors rotate.

FAQ

YouTrack returns 401 to my gateway tests

Confirm the header name in your handler matches the Webhook Triggers setting, ensure no trailing whitespace in the token field, and verify TLS termination does not strip custom headers at the load balancer.

Comments succeed from curl but not from OpenClaw

Check that the permanent token still has comment permission for the project, confirm you target the REST issue id (not only the human-readable number), and read API error bodies for schema or throttle hints.

Chat shows duplicate success lines

Dedupe outbound webhooks on provider message keys; ensure only the gateway emits chat events, not individual worker scripts.

Do I need a catch-all webhook day one?

No—start with explicit events, prove idempotency and summaries, then widen coverage once logging volume is acceptable.