Summary
POST /api/v1/execute/async/<target> silently fails to register the webhook config from the request body. The execution runs and succeeds, but webhook_registered comes back false, no callback is ever delivered, and no error is surfaced to the caller.
Environment
- af v0.1.93 (built 2026-06-22), macOS (Darwin 25.2), control plane
af server on localhost:8080
- Long-running Go agent registered via the Go SDK
Reproduction
- Submit an async execution with a valid webhook config:
POST /api/v1/execute/async/deep_research.generate_document
{
"input": { "...": "..." },
"context": { "...": "..." },
"webhook": {
"url": "http://localhost:3000/api/webhooks/agent-orchestration",
"secret": "<secret>",
"headers": { "X-App-Webhook": "followthethread-v1" }
}
}
- Execution completes normally (
status: succeeded).
GET /api/v1/executions/<id> returns "webhook_registered": false. The callback URL never receives a request.
Observed on every async submission from this client, across two different reasoners and two agent nodes. The URL is well-formed (scheme + host, no embedded credentials), so current normalizeWebhookRequest validation in HEAD would accept it.
Impact
Any client relying on webhook completion notifications hangs forever on tasks whose results are actually ready. In our app, document-generation tasks sat in queued while the finished result was on the control plane. We worked around it with client-side polling that reads GET /api/v1/executions/<id> and ingests terminal results directly.
Expected
webhook_registered: true for a valid webhook config, with a callback on terminal state.- If registration is rejected, the async submit response should carry the rejection reason (a
webhook_error field) instead of failing silently.
Notes
- The async submit response also omits any webhook error detail, so clients can only detect the failure by reading back the execution record.
- Possibly fixed after 0.1.93; current handler source (
internal/handlers/execute.go, normalizeWebhookRequest) records a webhookError but we could not confirm the running binary matches. If it is fixed, a release + a webhook_error passthrough in the submit response would close this.
Summary
POST /api/v1/execute/async/<target>silently fails to register thewebhookconfig from the request body. The execution runs and succeeds, butwebhook_registeredcomes backfalse, no callback is ever delivered, and no error is surfaced to the caller.Environment
af serveron localhost:8080Reproduction
status: succeeded).GET /api/v1/executions/<id>returns"webhook_registered": false. The callback URL never receives a request.Observed on every async submission from this client, across two different reasoners and two agent nodes. The URL is well-formed (scheme + host, no embedded credentials), so current
normalizeWebhookRequestvalidation in HEAD would accept it.Impact
Any client relying on webhook completion notifications hangs forever on tasks whose results are actually ready. In our app, document-generation tasks sat in
queuedwhile the finished result was on the control plane. We worked around it with client-side polling that readsGET /api/v1/executions/<id>and ingests terminal results directly.Expected
webhook_registered: truefor a valid webhook config, with a callback on terminal state.webhook_errorfield) instead of failing silently.Notes
internal/handlers/execute.go,normalizeWebhookRequest) records awebhookErrorbut we could not confirm the running binary matches. If it is fixed, a release + awebhook_errorpassthrough in the submit response would close this.