Mohamed BoudraandGitHub
42f1d0b289
* docs(hub): align public docs with v0.3 Bring the public workflow, API, authority, activity, and self-hosting guidance in line with the released Hub contracts. Clarify the public HTTPS boundary required by provider events while keeping Hub and PostgreSQL private. * docs(hub): clarify daemon logout scope * docs(hub): restore Compose path and simplify TLS guidance * docs(hub): link the single-repo-team-bot example
3.7 KiB
3.7 KiB
title, description, nav, order, category
| title | description | nav | order | category |
|---|---|---|---|---|
| Hub activity | Read what Hub did with an event, tell a filtered event from an unrouted one, and debug a trigger that did nothing. | Activity | 72 | Hub |
Hub activity
Every event Hub accepts is recorded, whether or not it ran anything. That record is how you debug a trigger.
Where to look
Project → Activity lists routed trigger runs and their execution state.
Connections → Known unrouted events is the organization-level view of accepted provider events that did not start a configured trigger. Hub records one of four bounded reasons:
| Reason | Meaning |
|---|---|
no_project_route |
No project route is configured for the event |
no_trigger_for_source |
No configured trigger handles that event source |
trigger_filters_rejected |
A trigger handles the source, but its filters rejected it |
configuration_unavailable |
A relevant configuration or connection could not be resolved |
Nothing happened when I mentioned the bot
Work down this list.
- Is the event in the project's Activity? If not, check Connections → Known unrouted events and use its reason to distinguish routing, source, filter, and configuration failures.
- Is the event anywhere at all? If not, the event never reached Hub. Check the provider's own delivery log: GitHub's App → Advanced → Recent Deliveries, or Slack's Event Subscriptions page. Then check that the app is subscribed to that event type.
- Is your user in
from_users? This is the most common cause. GitHub uses your login; Slack and Discord use the user ID, not the display name. - Did the invocation match? On GitHub,
containsmust appear in the comment body. On Slack and Discord the bot must be mentioned, andpatternor its legacycontainsalias must prefix the text after the mention. - Is the configuration you think is active actually active? The Configuration tab shows the active revision and the last sync attempt. A failed push leaves the old revision serving.
- Is the daemon connected? An offline daemon fails dispatch with
daemon_not_connected. - Did it run and stop early? Compare the execution with the step's authored
idle_timeoutandmax_runtime, and the workflow'smax_runtime. All three limits are explicit in the workflow. - Did it run, but deliver nothing? Check the step's prompt. An agent that is not told to call
hub.replyandhub.finish_executioncan answer in its own transcript and never report back. See Tell the agent which tool to call.
Sync failures
The Configuration tab shows the latest sync state:
| State | What to do |
|---|---|
| Fetch failed | The file is missing at that commit, or the App can't read the repository |
| Invalid | Validation failed, or the config names something unreachable |
| Superseded push ignored | A newer commit already moved the branch head; nothing is wrong |
"Names something unreachable" is usually a repository the installation doesn't cover, a daemon that was renamed, or a connection slug that no longer exists. See How Hub works.
Nothing is retried
Hub does not queue events. A dispatch that fails because the daemon was offline stays failed, so trigger it again once the daemon is back.