Found while testing the workflows endpoints against eu.cloud.agenta.ai for the v0.96 REST API migration docs (PR-6 Workflows).
POST /api/workflows/variants/fork responds HTTP 200 {"count": 0} regardless of the request body. No validation error, no server-side error raised to the client.
Repro
- Create a workflow, a variant with a unique slug, and commit at least one revision on that variant.
- Call fork:
curl -s -X POST "$AGENTA_HOST/api/workflows/variants/fork" \
-H "Authorization: ApiKey $AGENTA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"workflow": {"workflow_id": "<artifact_id>", "workflow_variant_id": "<source_variant_id>", "workflow_variant": {"slug": "fork-experimental", "name": "experimental"}}}'
Response: HTTP 200 {"count": 0}.
Also tried with the core aliased shape (artifact_id / variant_id / variant) and with an empty body. All return the same.
Expected
Either a forked variant object, or a structured 4xx error pointing at the offending field.
Suspected cause
WorkflowsRouter.fork_workflow_variant delegates to workflows_service.fork_workflow_variant, which calls workflows_dao.fork_variant. fork_variant returns None when log_revisions(...) yields nothing. The source variant has revisions (verified via /workflows/revisions/log), so something upstream is dropping the variant_id supplied via the workflow wrapper — likely alias normalization on WorkflowFork / ArtifactFork isn't propagating workflow_variant_id -> variant_id for the fork payload.
At minimum the handler should 400 when no source revisions resolve from the supplied refs.
Impact
Fork via REST is unusable. Docs PR flags this and does not ship a worked fork example until it is fixed.
Found while testing the workflows endpoints against
eu.cloud.agenta.aifor the v0.96 REST API migration docs (PR-6 Workflows).POST /api/workflows/variants/forkrespondsHTTP 200 {"count": 0}regardless of the request body. No validation error, no server-side error raised to the client.Repro
Response:
HTTP 200 {"count": 0}.Also tried with the core aliased shape (
artifact_id/variant_id/variant) and with an empty body. All return the same.Expected
Either a forked variant object, or a structured 4xx error pointing at the offending field.
Suspected cause
WorkflowsRouter.fork_workflow_variantdelegates toworkflows_service.fork_workflow_variant, which callsworkflows_dao.fork_variant.fork_variantreturns None whenlog_revisions(...)yields nothing. The source variant has revisions (verified via/workflows/revisions/log), so something upstream is dropping thevariant_idsupplied via theworkflowwrapper — likely alias normalization onWorkflowFork/ArtifactForkisn't propagatingworkflow_variant_id->variant_idfor the fork payload.At minimum the handler should 400 when no source revisions resolve from the supplied refs.
Impact
Fork via REST is unusable. Docs PR flags this and does not ship a worked fork example until it is fixed.