Roadmap
Human-in-the-loop message waiting — what's blocking it and what's coming
message/sendAndWait.
The operation currently sends its message successfully via chat.postMessage, then
returns an ENGINE_NOT_SUPPORTED error rather than silently pretending to wait.
Intended behaviour
- Send a Slack message via
chat.postMessage. - Suspend the current workflow execution, storing a correlation token.
- Resume when a matching Slack event (a reply or reaction referencing that correlation token) arrives at an inbound webhook registered with Slack's Events API.
- Propagate the reply/reaction payload to downstream nodes.
Why it isn't live yet
Steps 2–4 require ProcessEngine-level workflow suspension infrastructure — the ability to pause a running workflow instance, persist its state, and resume it later from an external trigger. That infrastructure does not exist yet in ProcessEngine (tracked as ISSUE-04). Until it ships, sendAndWait is intentionally left returning a clear error rather than faking a wait or hanging indefinitely, so workflow authors are not misled into thinking replies are being captured when they are not.
What it will need once ProcessEngine support lands
- Workflow suspension/resume primitives in ProcessEngine (the actual dependency being tracked by ISSUE-04).
- An inbound webhook or Events API subscription wired to the workflow's correlation token, so a Slack reply/reaction can resume the correct suspended instance.
- Timeout handling honoring the existing
timeoutSecondsfield onSendAndWaitInfo(already present in the DTO, unused until suspension exists).
Everything else
All other 41 operations across message, channel, file, reaction, user, and userGroup are fully implemented and call their respective Slack Web API endpoints directly — there are no other known gaps in the current operation set.