Repository navigation
Trigger payload mapping UI and config validation #16
Description
Summary
Add first-class payload mapping for webhook/manual triggers so users can map incoming fields to task or knowledge fields without editing raw JSON or relying on fixed defaults.
Why
Current actions (create_task, add_knowledge, log_event) use simple conventions like title, description, content, and text. That is enough for MVP webhooks, but real sources vary (lead.name, body.message, document.text, etc.). Users need predictable mapping and validation.
Scope
- Add config schema for trigger action mappings.
- Support mappings for:
create_task: title, descriptionadd_knowledge: title, content, sourceUrllog_event: message or payload summary
- Add console UI controls in instance Settings -> Triggers.
- Add API validation/sanitization for mapping config.
- Preserve current default behavior when no mapping is configured.
- Include a small payload preview/test flow if feasible.
Acceptance Criteria
- A user can create/edit a webhook trigger and map payload paths to task/knowledge fields.
- Existing triggers without mappings continue to work.
- Invalid mapping paths/config return clear API errors.
- Manual
runcan test a payload and show success/failure in trigger events. - E2E covers creating a mapped trigger in the console.
- Unit tests cover mapping extraction, default fallbacks, and invalid configs.
Activity
feat(triggers): config validation + payload mapping, timezone-aware s…
serge-ivo commentedon Aug 6, 2026
Shipped in 2d9ca12.
Verified first — the ticket was accurate, and the underlying bug was worse than described. Trigger config was never validated at all:
POST/PUT /v1/triggersstoredsafeJson(body.config)verbatim,parseConfig(lib/triggers.ts) is a whitelist that drops unlisted fields before dispatch, andpresentTriggerechoed the raw stored JSON back. So a typo'dpipelin— or a correctly-spelled field belonging to a different action — was accepted, persisted, displayed in the console as configuration, and then silently ignored forever. The trigger looked configured and did nothing.Shipped
lib/trigger-config.ts—validateTriggerConfig(action, type, config). Create and update now 400 with the offending field named: unrecognised fields, recognised-but-wrong-action fields,timezone/jitterMinuteson a webhook, invalid mapping targets/paths, out-of-rangelimit/jitterMinutes.pipeline,collection,url, connectorprovider/grantId) is enforced for cron only. A webhook or manual run may legitimately supply those in the payload (dispatch already prefers payload over config), so requiring them there would break a working pattern; a cron has no payload, so a cron missing them can only ever fail at 3am.GET /v1/triggersnow returns the config through the whitelist parse, so what the console shows is what the dispatcher reads.POST /v1/triggers/previewreturns the same problems non-throwing, so the console surfaces them live as you type rather than only at the save button.config.mapping= target field → dotted payload path ({"title":"lead.name"}, array indices as segments). Mappable: create_task → title/description; add_knowledge → title/content/sourceUrl; log_event → message. A mapped path this payload lacks falls back to the existing convention, so adding a mapping can never make a working trigger produce less. Exposed over MCP too (create_instance_triggerconfig.mapping).Deliberately not done
Tests: 22 unit in
trigger-config.test.ts, 5 dispatch-level mapping tests intriggers.test.ts, 2 e2e.feat(connectors): a coder agent can comment on, close, relabel and as…
fix(triggers): re-enabling an auto-disabled cron re-anchors it, becau…