Slack writes work in this workspace. Slack events have never arrived. relayfile status puts a number on it:
workspace rw_7ccfea89 (default) mode: poll lag: 0s
github healthy queue lag 0s event active; last event 39m30s ago
slack lagging queue lag 0s event silent; last event 1748h12m22s ago
slack event feed silent for 1748h12m21s — queue lag 0s only means no queued work
1748 hours ≈ 73 days. Meanwhile the same connection posts digests to Slack every hour without issue, and deploy reports integrations.slack: already connected.
What we ruled out on the persona side
Two agents (x-reply-radar, x-tweet-competition) have never received an @-mention. Four configurations, none of which changed the symptom — no run at all, not a failed run:
| config |
result |
on: 'app_mention' |
no run (and it isn't a valid trigger — absent from KNOWN_TRIGGER_CATALOG, and normalizeSlackEventType returns null for it) |
on: 'message.created', match: '@mention', path …/messages/** |
no run |
+ useSubscription: true |
no run |
+ path widened to …/${SLACK_CHANNEL}/**, mount override removed |
no run |
The final configuration is byte-identical to agents in another workspace that demonstrably do receive Slack events (pr-shepherd, hn-monitor, joke-bot, inbox-buddy):
slack: [{ on: 'message.created', paths: ['/slack/channels/${SLACK_CHANNEL}/**'], match: '@mention' }]
Ingestion looks correct in code
slack-relay's fetch-channel-history.ts has an onWebhook handler that accepts both message and app_mention and does an immediate batchSave — so realtime delivery is implemented, and runs: "every hour" is reconciliation rather than the delivery path:
if (event.type !== 'message' && event.type !== 'app_mention') return null;
…
await nango.batchSave([record], MESSAGE_MODEL);
webhookSubscriptions lists app_mention, message.channels, message.groups, message.im, message.mpim.
Observed
A message sent at 08:02 UTC left last_event_at at 08:00:08 ten minutes later. /slack/channels/<id>/messages returns 404 in the VFS.
The bot is in the channel and the Slack app is reported as correctly configured.
Question
Is the webhook subscription actually registered for this connection? A 73-day silent feed on a connection whose writes are healthy suggests the inbound registration was never made (or lapsed), rather than anything in the persona layer — but relayfile status reporting lagging with queue lag 0s is easy to read as "fine", which is presumably why it went unnoticed for that long.
Suggestion regardless of cause: a silent event feed measured in days on an otherwise-healthy connection seems worth surfacing more loudly than a lagging label.
Slack writes work in this workspace. Slack events have never arrived.
relayfile statusputs a number on it:1748 hours ≈ 73 days. Meanwhile the same connection posts digests to Slack every hour without issue, and deploy reports
integrations.slack: already connected.What we ruled out on the persona side
Two agents (
x-reply-radar,x-tweet-competition) have never received an @-mention. Four configurations, none of which changed the symptom — no run at all, not a failed run:on: 'app_mention'KNOWN_TRIGGER_CATALOG, andnormalizeSlackEventTypereturnsnullfor it)on: 'message.created',match: '@mention', path…/messages/**useSubscription: true…/${SLACK_CHANNEL}/**, mount override removedThe final configuration is byte-identical to agents in another workspace that demonstrably do receive Slack events (
pr-shepherd,hn-monitor,joke-bot,inbox-buddy):Ingestion looks correct in code
slack-relay'sfetch-channel-history.tshas anonWebhookhandler that accepts bothmessageandapp_mentionand does an immediatebatchSave— so realtime delivery is implemented, andruns: "every hour"is reconciliation rather than the delivery path:webhookSubscriptionslistsapp_mention,message.channels,message.groups,message.im,message.mpim.Observed
A message sent at 08:02 UTC left
last_event_atat 08:00:08 ten minutes later./slack/channels/<id>/messagesreturns 404 in the VFS.The bot is in the channel and the Slack app is reported as correctly configured.
Question
Is the webhook subscription actually registered for this connection? A 73-day silent feed on a connection whose writes are healthy suggests the inbound registration was never made (or lapsed), rather than anything in the persona layer — but
relayfile statusreportinglaggingwithqueue lag 0sis easy to read as "fine", which is presumably why it went unnoticed for that long.Suggestion regardless of cause: a silent event feed measured in days on an otherwise-healthy connection seems worth surfacing more loudly than a
lagginglabel.