message_posted workflow triggers never execute on hosted relay (webhook/schedule/manual triggers work) #4288

Activity

1. juddkussrow commented on Aug 3, 2026

   

   juddkussrow

   on Aug 3, 2026

   More actions

   I may have a counter-example, plus a possible explanation for the negative result
   here.

   message_posted does fire on a hosted relay

   Tested today on autom8.communities.buzz.xyz.

   Workflow (ed7014d2-212c-4eb2-919b-d1d2bb001497), created via CLI:

   name: PROBE 1 — message fields
   enabled: true
   trigger:
     on: message_posted
     filter: 'str_starts_with(trigger_text, "PROBE:")'
   steps:
     - id: echo_fields
       action: send_message
       timeout_secs: 20
       text: |-
         PROBE-RESULT: message_posted
         text        = {{trigger.text}}
         author      = {{trigger.author}}
         message_id  = {{trigger.message_id}}

   Posted PROBE: hello to the channel. The workflow fired and posted its result
   in the same second — no manual trigger involved:

   22:37:04  me        PROBE: hello
   22:37:04  workflow  PROBE-RESULT: message_posted
                       text        = PROBE: hello
                       author      = 3cd8a94f6fad3ad1…
                       message_id  = 2e2b8ec027607f91…
   

   All template fields resolved. So on this hosted community, at least, the
   message_posted trigger path works end to end.

   Why the original test may not have fired

   The report describes a test workflow that adds an emoji reaction when it sees
   matching text. That step is affected by a separate bug:

   #2395 — "workflow: add_reaction action calls a nonexistent relay endpoint — any
   workflow using it always fails"

   If that's accurate, the trigger may well have fired correctly and the action
   failed, which from the outside is indistinguishable from "the trigger never
   executed" — especially with run history unavailable.

   Worth re-testing with a send_message step instead of add_reaction. If it
   posts, the trigger was never the problem.

   On the diagnosis gap

   Strong agreement with the secondary point in the original report. In our case,
   workflows runs returned [] throughout (#2980), and the Desktop workflows
   list showed nothing at all for unrelated reasons (#2385 — multi-value #h
   filters collapsing). With triggers, actions, run history, and the list view each
   failing differently and silently, there was no way to tell which layer was
   broken.

   We only got clarity by making the workflow post a message containing its own
   trigger context — that turned the channel itself into the diagnostic surface,
   which is the one thing that still worked. Might be a useful debugging suggestion
   for others landing on this issue.

   Happy to run further tests against this hosted community if it would help.
2. luthen-seas commented on Aug 10, 2026

   

   luthen-seas

   on Aug 10, 2026

   Contributor

   More actions

   Second data point, and it extends the scope: reaction_added is affected too, so this is the whole channel-event trigger class rather than message_posted specifically.

   Environment

   • Hosted relay on *.communities.buzz.xyz, checked 2026-08-09
   • Workflow created via the relay's POST /events (kind:30620 directly), not Desktop
   • Trigger reaction_added, no emoji filter; single call_webhook step
   • Signed by a channel owner, so SEC-006 passes at save (the same definition signed by a non-admin agent is correctly refused with forbidden: workflows with call_webhook actions require the owner or admin role)

   What happened

   The definition saves and reads back cleanly — a #h-scoped kind:30620 query returns it. Reactions were then added to messages in that channel over several hours. The webhook target is an endpoint we operate, so we have full request logs rather than an inference: zero requests arrived, across two separate deployments, with the endpoint verified live and answering on other paths throughout.

   Same relay, same channel, same period: our own scheduled poller reading reactions over POST /query works continuously, so relay ingest of the kind:7 events themselves is fine. It is specifically the workflow dispatch that never happens.

   On the "hard to self-diagnose" point

   Strongly seconding it. Between run history returning [] (#2980) and the Desktop workflows list showing empty on hosted (#4696), there is no signal available to a user distinguishing never fired from fired and did nothing. We only established it because the webhook target was ours to instrument. Without that we would have concluded our own endpoint was at fault.

   One suggestion, if it's cheap: even a relay-side log line at dispatch — workflow <id> matched/skipped for event <kind> — would collapse this from a day to a minute, independent of whether #2980 gets fixed.

   Happy to run any probe against the hosted relay that would help narrow it.