Any reason system tenant can't have hooks?

[bclermont]

related to #1224

Why tenanant system can't set up hooks?

[mrgoonie]

Summary: I checked the hook schema and store guards. There is no inherent rule that the system/master tenant cannot have hooks; master-scope/global hooks are explicitly supported.

Decision: needs-info / likely UI/API path or PR-specific regression, not a schema limitation

Evidence:

• migrations/000052_agent_hooks.up.sql says global-scope hooks use MasterTenantID (0193a5b0-7000-7000-8000-000000000001) as tenant_id, aligned with store.MasterTenantID, and the table default uses that same value.
• internal/store/context.go IsMasterScope treats unset tenant, owner role, or MasterTenantID as master scope.
• internal/store/pg/hooks.go only applies tenant visibility restrictions when !store.IsMasterScope(ctx); master scope can list by tenant filter or operate server-wide.
• Hook lookup intentionally returns tenant-specific + global hooks for non-master callers, so system/global hooks are meant to be visible as global hooks.

Next step: please share the failing path from #1224: UI/API/CLI route, exact error, and whether the request context has owner role or tenant_id=0193a5b0-7000-7000-8000-000000000001. If the dashboard blocks selecting/saving the system tenant, that should be fixed in the route/UI validation layer; if PGHookStore.Create rejects it directly, share the DB error and we should treat that as a store regression.

[bclermont]

Thanks for investigating. To clarify the specific problem:

The issue is not about creating global-scope hooks (which work fine for master scope). The problem is creating tenant-scoped or agent-scoped hooks targeting agents that live on the system/master tenant (0193a5b0-7000-7000-8000-000000000001).

In practice:

• When a user operates in master-scope context, their tenant_id in context resolves to the sentinel MasterTenantID
• Trying to create an agent-scoped or tenant-scoped hook for an agent whose tenant_id = MasterTenantID hits an ambiguity: the sentinel UUID is used both as "I am in global scope" and as "this row belongs to the system tenant"
• The hook creation flow (handleCreate) checks IsMasterScope(ctx) to skip tenant validation — but that also means it may not properly bind the system tenant's UUID as the hook's tenant_id when targeting agents on that tenant

The symptom: a master-scope user with agents on the system tenant cannot create scoped hooks for those agents through the normal UI/API flow. The workaround we hit was manually moving agents to a real (non-master) tenant in the database to be able to create hooks for them.

The fix in 9fce99a1 addressed tenant_id not being populated for ScopeTenant/ScopeAgent hooks, but only for non-master contexts. The master-scope path through handleCreate may still not correctly set tenant_id = MasterTenantID for agent-scoped hooks when the agent itself lives on the system tenant.

Worth checking: in handleCreate, when IsMasterScope(ctx) is true and cfg.Scope == ScopeAgent, is tenant_id explicitly set to MasterTenantID, or is it left unset/zero?

[mrgoonie]

Summary: I re-checked the create path with your clarified system-tenant/agent-scoped case. The current code does not leave tenant_id zero; it fills it from context, but then validation rejects the master/system tenant for non-global hooks.

Decision: confirmed / accepted bug

Evidence:

• internal/gateway/methods/hooks.go handleCreate does this for tenant/agent scope when tenant_id is omitted: cfg.TenantID = store.TenantIDFromContext(ctx).
• internal/store/context.go shows owner/master scope can carry tenant_id = MasterTenantID (0193a5b0-7000-7000-8000-000000000001), and gateway connect defaults owner/no-hint contexts to that tenant.
• internal/hooks/types.go defines hooks.SentinelTenantID = store.MasterTenantID for global hooks.
• internal/hooks/config.go validateScope currently rejects ScopeTenant and ScopeAgent when TenantID == SentinelTenantID, returning hook: tenant scope requires a real tenant_id or hook: agent scope requires a real tenant_id.

So the blocker is not a zero/empty tenant_id; it is that the same UUID is overloaded as both the real system tenant and the global-hook sentinel, and validation forbids using it for tenant/agent scope.

Next step: fix the hook scope model so global scope is represented separately from “system tenant” for validation, or explicitly allow MasterTenantID for tenant/agent scoped hooks when the target agent belongs to that tenant and the caller is master/owner. Add regression coverage for creating a ScopeAgent hook targeting an agent with tenant_id = MasterTenantID, because #1224 currently does not cover this clarified path.

[bclermont]

PR submitted: #1280

Fix threads isMasterScope bool into Validate() / validateScope() in internal/hooks/config.go. The sentinel UUID (MasterTenantID) is now only rejected for non-master callers on tenant/agent scope — master/owner callers targeting the system tenant row are explicitly allowed. uuid.Nil remains always rejected. All builds pass.