@relayflows/surface 2.0.13 → 2.0.15
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/triggers/README.md +13 -0
package/package.json
CHANGED
package/src/triggers/README.md
CHANGED
|
@@ -15,6 +15,19 @@ webhook sources: their executor/inbox name is the provider, and their filter
|
|
|
15
15
|
matches the provider, event type, and requested payload fields. Register those
|
|
16
16
|
provider names in `flows.json`'s `executors` array for preflight.
|
|
17
17
|
|
|
18
|
+
Registration and deliverability are separate checks. `flows check` also refuses
|
|
19
|
+
a subscription on a provider inbox that pins an event type the provider does not
|
|
20
|
+
publish, reading this same generated vocabulary, so the refusal arrives while
|
|
21
|
+
authoring rather than from ingress on the first real event. The generated
|
|
22
|
+
namespaces above can only produce valid declarations; the refusal exists for
|
|
23
|
+
hand-written `webhook(provider, { provider, type })` sources.
|
|
24
|
+
|
|
25
|
+
It is deliberately narrow. A provider trigger *is* a webhook, so a filter alone
|
|
26
|
+
cannot prove intent: `webhook('deploys', { provider: 'aws' })` is a valid generic
|
|
27
|
+
inbox matching a payload field that happens to be named `provider`. A source is
|
|
28
|
+
read as a provider subscription only when its inbox is a generated provider, the
|
|
29
|
+
filter names that same provider, and the filter pins an event type.
|
|
30
|
+
|
|
18
31
|
`slack.mention(channel)` subscribes to Slack's `app_mention` event;
|
|
19
32
|
`slack.reaction(emoji)` subscribes to `reaction_added`. Arguments match provider
|
|
20
33
|
values exactly: use the channel ID and reaction name from the incoming event.
|